StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p><strong>It seems to me that you are operating on at least one false assumption.</strong></p> <h2>1. You don't need to raise the ProgressChanged event to have a responsive UI</h2> <p>In your question you say this:</p> <blockquote> <p>BackgroundWorker is not the answer because it may be that I don't get the progress notification, which means there would be no call to ProgressChanged as the DoWork is a single call to an external function . . .</p> </blockquote> <p>Actually, <strong>it does not matter whether you call the <code>ProgressChanged</code> event or not</strong>. The whole purpose of that event is to temporarily transfer control back to the GUI thread to make an update that somehow reflects the progress of the work being done by the <code>BackgroundWorker</code>. <strong>If you are simply displaying a marquee progress bar, it would actually be pointless to raise the <code>ProgressChanged</code> event at all</strong>. The progress bar will continue rotating as long as it is displayed because <strong>the <code>BackgroundWorker</code> is doing its work on a separate thread from the GUI</strong>.</p> <p>(On a side note, <code>DoWork</code> is an event, which means that it is not <em>just</em> "a single call to an external function"; you can add as many handlers as you like; and each of those handlers can contain as many function calls as it likes.)</p> <h2>2. You don't need to call Application.DoEvents to have a responsive UI</h2> <p>To me it sounds like you believe that <em>the only</em> way for the GUI to update is by calling <code>Application.DoEvents</code>:</p> <blockquote> <p>I need to keep call the Application.DoEvents(); for the progress bar to keep rotating.</p> </blockquote> <p><strong>This is not true in a multithreaded scenario</strong>; if you use a <code>BackgroundWorker</code>, the GUI will continue to be responsive (on its own thread) while the <code>BackgroundWorker</code> does whatever has been attached to its <code>DoWork</code> event. Below is a simple example of how this might work for you.</p> <pre><code>private void ShowProgressFormWhileBackgroundWorkerRuns() { // this is your presumably long-running method Action<string, string> exec = DoSomethingLongAndNotReturnAnyNotification; ProgressForm p = new ProgressForm(this); BackgroundWorker b = new BackgroundWorker(); // set the worker to call your long-running method b.DoWork += (object sender, DoWorkEventArgs e) => { exec.Invoke(path, parameters); }; // set the worker to close your progress form when it's completed b.RunWorkerCompleted += (object sender, RunWorkerCompletedEventArgs e) => { if (p != null && p.Visible) p.Close(); }; // now actually show the form p.Show(); // this only tells your BackgroundWorker to START working; // the current (i.e., GUI) thread will immediately continue, // which means your progress bar will update, the window // will continue firing button click events and all that // good stuff b.RunWorkerAsync(); } </code></pre> <h2>3. You can't run two methods at the same time on the same thread</h2> <p>You say this:</p> <blockquote> <p>I just need to call Application.DoEvents() so that the Marque progress bar will work, while the worker function works in the Main thread . . .</p> </blockquote> <p>What you're asking for is <strong>simply not real</strong>. The "main" thread for a Windows Forms application is the GUI thread, which, if it's busy with your long-running method, is not providing visual updates. If you believe otherwise, I suspect you misunderstand what <code>BeginInvoke</code> does: it launches a delegate <strong>on a separate thread</strong>. In fact, the example code you have included in your question to call <code>Application.DoEvents</code> between <code>exec.BeginInvoke</code> and <code>exec.EndInvoke</code> is redundant; you are actually calling <code>Application.DoEvents</code> repeatedly from the GUI thread, <strong>which would be updating anyway</strong>. (If you found otherwise, I suspect it's because you called <code>exec.EndInvoke</code> right away, which blocked the current thread until the method finished.)</p> <p>So yes, the answer you're looking for is to use a <code>BackgroundWorker</code>.</p> <p>You <em>could</em> use <code>BeginInvoke</code>, but instead of calling <code>EndInvoke</code> from the GUI thread (which will block it if the method isn't finished), pass an <code>AsyncCallback</code> parameter to your <code>BeginInvoke</code> call (instead of just passing <code>null</code>), and close the progress form in your callback. Be aware, however, that if you do that, you're going to have to invoke the method that closes the progress form from the GUI thread, since otherwise you'll be trying to close a form, which is a GUI function, from a non-GUI thread. But really, all the pitfalls of using <code>BeginInvoke</code>/<code>EndInvoke</code> have already been dealt with <em>for</em> you with the <code>BackgroundWorker</code> class, even if you think it's ".NET magic code" (to me, it's just an intuitive and useful tool).</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

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