dispatcher invoke async await .net 4.6.1 - wpf

Question

I am targeting WPF .NET 4.6.1.
I am constantly doing this:
btnClick
{
Task T1 = Task.Run<List<Double>>( AsyncFunction );
T1.Wait(.1);
Dispatcher.Invoke(() => { txtStatus.Text+="HOLD ON.."; };
T1.Wait(.1);
}
The only way I can get this to actually update the UI between these Wait(s) is to do:
Dispatcher.Invoke(new Action(()=>{}),priority: DispatcherPriority.ApplicationIdle);
Is this right? Is this portable? Describe discuss different approaches on different platforms (UWP, Windows 10 Phone).
Possibly see Raymond Chen: https://devblogs.microsoft.com/oldnewthing/20190327-00/?p=102364
I explicity do not want to use Async Button Event because I need to be able to help the user, at least put logic for a tenth of a second completion check and not have the user slamming the async button handler trying to get results and congesting my sensor network with data.
You know I eventually want to get the result of this too, and process it, IN THE SAME EVENT HANDLER CODE, so like I don't want to use BackroundWorker and then have the user have to Click another button to poll the Results, which may STILL BE EMPTY and make everybody REALLY REALLY MAD. And I don't want to Poll the results automatically and then poll the sensors network again and cause MORE congestion.

Answer 1

I explicity do not want to use Async Button Event because I need to be able to help the user, at least put logic for a tenth of a second completion check and not have the user slamming the async button handler trying to get results and congesting my sensor network with data.
The easiest solution is to do it the way everyone else solves it: disable the button while the operation is in progress.
async btnClick
{
btn.Enabled = false;
try
{
txtStatus.Text += "HOLD ON..";
var result = await Task.Run(() => AsyncFunction());
... // update UI with result.
}
finally { btn.Enabled = true; }
}

Answer 2

As an interim update, my testing indicates that both async event handlers and small synchronous Wait(s) are both appropriate approaches. I am achieving significantly better initial response by delegating only Wait(.1) to the network operation, initiating a DispatcherInvoke(()=>{txtStatus+="WAIT.."} and immediately followed by Dispatch(() =>{;//}, DispatcherPriority.ApplicationIdle).
Using an async event handler, and IProgress (you don't even need Dispatcher, just alter a bound control) inside the network call results in similar progress update, but with an initial response that may not be acceptable.
Using the synchronous waits results in a stalling of the UI Paint that makes any gradually updating progress bar appear very jerky.
For me, the progress bar being jerky is not the issues, because I am giving the operator direct feedback with WAIT.. WAIT .. WAIT ..And all the progress bar is doing is showing, by stalling, how backed up the thing is, but I retain enough synchronous control to jam an oscillating CAUTION in there. The oscillation may be jerky but trained operators will know, if that CAUTION keeps toggling, however unevenly, you are on, even if the gradual progress bar stalls and starts.
And, I can detect this in synchronous code, and then do something about it on the fly, like, offload the whole network call and then force the user to queue and poll.
UPDATE
async Task<List<Double>> NetworkList(IProgress<Int32> NetworkProgress)
{
List<Double> _results = new List<Double>();
foreach(var aNetwork in LotsOfNetworksCouldTakeAwhile)
{
SendPingFarAwayLand();
await Task.Delay(delay: TimeSpan.Frommilliseconds(100);
Double PingTime = GetPingTimeOrNull();
_results.Add(PingTIme);
NetworkProgress.Report( aNetwork.NetworkID );
}
}
async btnClick
{
TimeSpan IDLE_LONG_ENOUGH_SO_DISPATCHER_UPDATES_UI = TimeSpan.FromMilliseconds(50);
txtStatus += "WORKING...";
await Task.Delay(delay: IDLE_LONG_ENOUGH_SO_DISPATCHER_UPDATES_UI);
Task<List<Double>> results = await NetworkList(_Progress);
dependencyObject1.ObservableList1.Add(results);
return;
}
This seems to work at least on my computer. About 50 millis is enough to guarantee the dispatcher processes your latest "WORKING..." message immediately. If you don't, you may hit the dispatcher on an up cycle, but maybe not, and it will start on LongNetworkList and it may be a half second before you even see that something is happening.
It's almost like do you want the sprint team captain to hit the stopwatch, or run with you. Delay of 50 millis to even start on the work seems like a lot if you are trying to ping two sub 10ms networks. But if you have even one aberrant one in there that immediately takes up the whole 100ms await and STILL doesn't return anything for you to report progress on, it's nice to have put up something on the screen.
Kudos to Cleary, I'm switching to Reactive.NET, right after lunch.