Who is using BusyIndicators?

[Fabrice]

Hi Dick,
for this kind of things, you can also use the BackgroundWorker class.
It works the same way with WinForms and WPF.
You create the object, attached event for DoWork, ProgressChanged, RunWorkerCompleted.
So you can RunWorkerAsync()...that will launch the DoWork event; this event can ReportProgress(), and you can update your UI in ProgressChanged; and you are notified when the job is done through RunWorkerCompleted(); and at anytime you can CancelAsync() the task if needed.

Then, you don't have to bother about these await/async/Task/Thread things...

My 2 cents,
Fab

[ArneOrtlinghaus]

Nice living discussion! Every answer gives additional details.
Arne

[NickFriend]

Hi Fab,

for this kind of things, you can also use the BackgroundWorker class.
It works the same way with WinForms and WPF.
You create the object, attached event for DoWork, ProgressChanged, RunWorkerCompleted.
So you can RunWorkerAsync()...that will launch the DoWork event; this event can ReportProgress(), and you can update your UI in ProgressChanged; and you are notified when the job is done through RunWorkerCompleted(); and at anytime you can CancelAsync() the task if needed.

Then, you don't have to bother about these await/async/Task/Thread things...

BackgroundWorker is a perfectly good solution for this case, however I'd strongly encourage people to look at the Task model. Once you've got the pattern established in your code, it's incredibly easy to make any process asynchronous with very little effort and virtually no changes to existing data access or business logic.

Nick

[ic2]

Hello Nick,

BackgroundWorker is a perfectly good solution for this case, however I'd strongly encourage people to look at the Task model. Once you've got the pattern established in your code, it's incredibly easy to make any process asynchronous with very little effort and virtually no changes to existing data access or business logic.

I agree with you that using Tasks (or Threads, the alternative I described above) were both quick to implement. But apparently they do not guarantee true multitasking as in all cases the movement of the BusyIndicator stalled. In the above thread sample 2 tasks were creating output which indeed shows an alternate line from 1 and then the other process. That works. The BusyIndicator did not.

Running a separate exe seems like a low tech solution but it's the only thing which works. To the current version I added parameters which I can pass using ProcessStartInfo so I can also show where the user is waiting for. Using a modified version of an earlier used RunSafe (returning the correct values to later close the opened window, which is basically done with ShellExecuteEx, I can open & close the very same BusyIndicator WPF window from VO too.

Dick