Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<blockquote> <p>Does the behavior of Invoke changes on different Win OS? </p> </blockquote> <p>It should not, no. But, threading problems can materialize in very unpredictable ways. It is possible that you have an unidentified problem.</p> <blockquote> <p>What are the other ways of updating UI from thread apart from Invoke?</p> </blockquote> <p>Using <code>Invoke</code> or <code>BeginInvoke</code> 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 <code>BackgroundWorker</code> uses this mechanism exclusively for updating the UI through its <code>ProgressChanged</code> event.</p> <p>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.</p> <ul> <li><code>Invoke</code> and <code>BeginInvoke</code> are expensive operations.</li> <li>The UI thread gets to dictate when and how often to update the form and its controls.</li> <li>It eliminates the tight coupling between UI and worker threads that <code>ISynchronizeInvoke</code> imposes.</li> <li>There is no risk of overrunning or saturating the UI message queue with a bunch of marshaling operations.</li> <li>You get more throughput on the worker thread since it does not have to wait for response as would be the case with <code>Invoke</code>.</li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload