WPF and WinUI: Improve mouse-move behavior in OfflineRouting sample

[mstefarov]

Description

This sample calls an async UpdateRoute method on MouseMoved event, but does not wait for it to finish. That causes multiple parallel calls to UpdateRoute to execute at the same time -- I've seen as many as 10 in parallel. The implications of that are:

1) The sample burns system resources and can appear unresponsive 2) The shared _offlineRouteParameters are used in a thread-unsafe way 3) There is no guarantee that most-recent call to UpdateRoute is the one that completes last -- instead, whichever of the parallel calls take the longest get to update the graphics last.

To improve on this, I added some rudimentary guards against parallel execution to the samples. The sample feels much more responsive with these changes, and does not lock up any more:

https://github.com/user-attachments/assets/05a21202-1845-41f2-8e10-0496f8d1f2e0

MAUI sample did not need any changes, because it does not update route on mouse-move.

Note that most changes in the PR are due to indentation, and ignoring whitespace changes makes for a more readable diff: https://github.com/Esri/arcgis-maps-sdk-dotnet-samples/pull/1490/files?w=1

Type of change

• Bug fix

Platforms tested on

• [x] WPF .NET 8
• [x] WPF Framework
• [x] WinUI
• [ ] MAUI WinUI
• [ ] MAUI Android
• [ ] MAUI iOS
• [ ] MAUI MacCatalyst

Checklist

• [x] Self-review of changes
• [x] All changes work as expected on all affected platforms
• [x] There are no warnings related to changes
• [x] Code is commented and follows .NET conventions and standards
• [x] Codemaid and XAML styler extensions have been run on every changed file
• [x] No unrelated changes have been made to any other code or project files
• [ ] Screenshots are correct size and display in description tab (800 x 600 on Windows, MAUI mobile platforms use the MAUI Windows screenshot)

[duffh]

Definitely an improvement, I noticed a bit of an issue where when moving the mouse around and recalculating the route it occasionally throws an exception as no solution is found. This updates the error message to display an error which remains until the map is tapped.

It doesn't prevent using the sample, I don't think it's a major issue but we may need to revisit the error messaging.

[duffh]

I've removed the error messaging while the cursor is moving + the route is being calculated as I don't think it makes sense to show an error in the UI before the map has been tapped.

We still alert the user in the event a stop cannot be added so I think this change is fine to make.