2

My application is heavily depended on threads to do the complex processing of very large data. The UI needs to be updated as the processing is being done. I know and tried to used BackgroundWorker's OnProgressChanged and RunWorkerCompleted methods to update the UI. Also using Invoke method of the UI thread to update. Everything seems to work fine on Win XP 32 bit and 64 bit OS. On Win Vista and Win 7 (32 and 64 bit), the application randomly hangs while updating the UI by using Invoke method.

Does the behavior of Invoke changes on different Win OS? What are the other ways of updating UI from thread apart from Invoke?

Thanks

Vinod Maurya
  • 4,167
  • 11
  • 50
  • 81
  • My assumption that in different OS's and environments, it just plain takes longer to update the UI. – RQDQ Mar 22 '12 at 15:21
  • 1
    I don't think that the problem is the new OS - my guess is that either the new machine is just faster/has more cores (so concurrency issues might arrive earlier) or you just got lucky - anyhow: without code I don't think we can help you – Random Dev Mar 22 '12 at 15:21
  • 1
    Application do not response, or do not refresh itself? – Sergey Berezovskiy Mar 22 '12 at 15:30
  • @lazyberezovsky application does response but it does not refresh itself – Vinod Maurya Mar 23 '12 at 09:49
  • 1
    Then try to call Application.DoEvents() after each UI update, as I stated in my answer below. This forces to process refresh messages in window loop. – Sergey Berezovskiy Mar 23 '12 at 10:01

4 Answers4

2

Not sure what's going wrong, but you could always just have a System.Windows.Forms.Timer running that updates the GUI periodically; use some member variables to pass raw data between threads, inside locks if necessary. Not the most elegant solution, but it might give you a different perspective into what's hanging since the threads are more independent this way, rather than relying on a background thread to Invoke your main thread.

Dax Fohl
  • 10,654
  • 6
  • 46
  • 90
2

Does the behavior of Invoke changes on different Win OS?

It should not, no. But, threading problems can materialize in very unpredictable ways. It is possible that you have an unidentified problem.

What are the other ways of updating UI from thread apart from Invoke?

Using Invoke or BeginInvoke are way overused especially when trying to report simple progress information to the UI thread. If you search for some of my answers related to the subject you will see that I rip on this approach all of the time. And for good reason since their are many disadvantages to using this technique. It is unfortunate that BackgroundWorker uses this mechanism exclusively for updating the UI through its ProgressChanged event.

One alternate method is to have your worker thread publish progress information into a shared variable and have the UI thread poll for it periodically via a timer. Here are some of my usual talking points in justifying this approach over the marshaling techniques.

  • Invoke and BeginInvoke are expensive operations.
  • The UI thread gets to dictate when and how often to update the form and its controls.
  • It eliminates the tight coupling between UI and worker threads that ISynchronizeInvoke imposes.
  • There is no risk of overrunning or saturating the UI message queue with a bunch of marshaling operations.
  • You get more throughput on the worker thread since it does not have to wait for response as would be the case with Invoke.
Brian Gideon
  • 47,849
  • 13
  • 107
  • 150
  • I can vouch for this method. I have written an application that receives 100s of on updates per second. (over middleware) It is ridiculous to attempt to display each and everyone so i use the method outlined above. The result is a much more useable ui. – Fen Mar 22 '12 at 16:26
1

You could try using one of the Invoke() or BeginInvoke() overloads that takes a Dispatcher.Priority enum as a parameter. If you select a parameter such as 'Background' you should see your application is still responsive. The only issue then becomes ensuring you are servicing your incoming data at an adequate rate without an ever increasing queue.

Sogger
  • 15,962
  • 6
  • 43
  • 40
0

Another option would be to forego the multithreading entirely. If your long-running operation can be broken up into chunks, do it in the GUI thread and use Application.DoEvents() when you want to update the GUI.

I used to dislike use of that method since it could not only update the GUI but also start responding to user input, kicking off timers, etc., but ultimately it's no less safe than using a background thread, which allows the GUI to start doing anything at any time. So probably after each call of Application.DoEvents() you'd need to check _canceled or whatever. (I eventually decided I dislike the existence of this method, since it eliminates the guarantees of linear execution order, than the use of it).

Of course you lose multicore support this way, so it'd affect performance if you're trying to run lots of background ops at the same time.

Dax Fohl
  • 10,654
  • 6
  • 46
  • 90