Keeping your UI Responsive and the Dangers of Application.DoEvents

re: Keeping your UI Responsive and the Dangers of Application.DoEvents

zzz — Sun, 07 Aug 2005 01:05:31 GMT

Too bad the DoEvents docs doesn't mention anything like: This method is mostly used for workaround purposes. Use method/pattern X instead.

There is a sample that suggests example use of "Call Application.DoEvents to force a repaint". I guess that's workaround when you need to "force". Isn't having such samples suggest that DoEvents is the correct way of doing x instead of being a workaround.

It would be good if such workaround methods had a clear note like this blog entry that if you need to use it you may have a bad design or whatever.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWindowsFormsApplicationClassDoEventsTopic.asp

Blog link of the week 31

Daniel Moth — Mon, 08 Aug 2005 01:58:49 GMT

Blog link of the week 31

Any threading-related issues with Application.Run()?

Vladimir Klisic — Mon, 08 Aug 2005 10:17:00 GMT

If I need to create a window (not necessarily a Form, could be a NativeWindow) in a separate thread, it would need to run its own message loop -- something like the old PeekMessage/TranslateMessage/DispatchMessage loop.

Looks like calling Application.Run() from that thread is the way to do that, but are there any special considerations when calling Application.Run() from another thread (other that the main one that already called it)?

Would it be a good idea to do it at all?

re: Keeping your UI Responsive and the Dangers of Application.DoEvents

Jankrod — Wed, 10 Aug 2005 00:53:53 GMT

So Maybe you can help me. My current use for a possible DoEvent is to keep the application resizable, movable, and minimize-able when doing heavy processing. DoEvents can do this for me, but I don't want any of the elements on the screen to be active. With the DoEvent you can minimize, but you can also click on other things and that mess up stuff when I'm trying to do calculations.

What I really want is a DoMinimizeAndMaximizeEvent, so some way to call the events directly, but not all of them. I can check with GetQueueStatus, if one of those are in the queue but I cant restrict the other event from going into the queue.

Getting away from Application.DoEvents

sano the super geek — Sun, 14 Aug 2005 19:32:41 GMT

Another great blog entry by Jessica Fosler: Keeping your UI Responsive and the Dangers of Application.DoEvents...

re: Keeping your UI Responsive and the Dangers of Application.DoEvents

ShadowChaser — Sun, 14 Aug 2005 20:45:14 GMT

I agree completely about Application.DoEvents. Don't forget that it also adds objects to the garbage collector each time it is run, creating memory & performance issues when placed in a tight loop.

That said, developers are really backed against a wall when developing WinForms apps that need code to "hook" into the main application loop, like games. There are no easy solutions outside of nasty hacks or building from the ground up using Interop

re: Keeping your UI Responsive and the Dangers of Application.DoEvents

jfoscoding — Mon, 15 Aug 2005 19:17:39 GMT

zzz - you have a great point RE the docs, I'll file a bug against the documentation. You're also welcome to file a bug using product feedback:
http://lab.msdn.microsoft.com/productfeedback/

re: Keeping your UI Responsive and the Dangers of Application.DoEvents

jfoscoding — Mon, 15 Aug 2005 19:33:33 GMT

Vladimir:
I assume you're thinking about doing some message passing or something?

Running the message loop on the second thread in and of itself wont be a problem, I think stopping it will. If you dont stop the message loop on the second thread, the program wont exit:

Try runnning this under the debugger

Thread t = new Thread(new ThreadStart(NewThread));
t.Start();
}

[STAThread]
private void NewThread() {
Application.Run();
}

If you dont kill the message pump on the second thread, you'll notice in the debugger that while the form closes, the application doesnt exit.

One way you could manage the lifetime of the message pump on the second thread is to use an ApplicationContext:

[STAThread]
private void NewThread() {
Application.Run(new BackgroundThreadApplicationContext(this));
}

public class BackgroundThreadApplicationContext : ApplicationContext {
public BackgroundThreadApplicationContext(Form mainForm) {
if (mainForm != null) {
mainForm.Closing +=new CancelEventHandler(mainForm_Closing);
}
}

private void mainForm_Closing(object sender, CancelEventArgs e) {
Form mainForm = sender as Form;
if (mainForm != null) {
mainForm.Closing -=new CancelEventHandler(mainForm_Closing);
}
this.ExitThread();
}
}

More details of how to use ApplicationContext are up at
http://www.windowsforms.net/articles/notifyiconapplications.aspx

re: Keeping your UI Responsive and the Dangers of Application.DoEvents

jfoscoding — Mon, 15 Aug 2005 19:40:14 GMT

Jankrod -
I dont know if it's possible, but I'd try moving the "heavy processing" to a background thread and update your UI in chunks. You may also want to Thread.Sleep the "heavy processing" thread to yield some time back to your UI thread so that it has the opportunity to be a little more responsive to users.

In Whidbey the BackgroundWorker API helps make this easy, but it's just a fluffy layer on what was already out there in 1.0/1.1 - just use Invoke and/or BeginInvoke to communicate back with the main UI.

An example is here
http://blogs.msdn.com/jfoscoding/archive/2005/05/26/422405.aspx

re: Keeping your UI Responsive and the Dangers of Application.DoEvents

jfoscoding — Mon, 15 Aug 2005 19:44:39 GMT

ShadowChaser:

Regarding the games thing, you might be right, although given a specific example there might be a workaround.

Regarding hooking into the message loop, any class can implement IMessageFilter and respond to a particular window message.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemwindowsformsimessagefilterclasstopic.asp

See all about handles in windows forms as it may have some more tips for you here..
http://blogs.msdn.com/jfoscoding/archive/2004/11/24/269416.aspx

Keeping your UI Responsive and the Dangers of Application.DoEvents

Link Blog — Tue, 16 Aug 2005 14:26:18 GMT

jfo's coding : Keeping your UI Responsive and the Dangers of Application.DoEvents
What&rsquo;s the difference...

re: Keeping your UI Responsive and the Dangers of Application.DoEvents

Vladimir Klisic — Tue, 16 Aug 2005 18:44:25 GMT

Thanks Jessica,

Actually I had the ApplicationContext in mind but I was in a short intellectual coma when I was writing my question.

Here's what I really wanted to ask: assuming that I do pass an ApplicationContext to a second thread (see the code below), are there any threading or other issues if both threads wait for the same (main) Form to close (within their respective Application.Run calls)?

Code:

<main thread>
static void Main()
{
MyMainForm mainForm = new MyMainForm();
ApplicationContext applicationContext = new ApplicationContext(mainForm);

// Create second thread
// Pass applicationContext to that thread, or somehow made it accessible from there

Application.Run(); // or Application.Run(mainForm), I guess it doesn't make a difference (?)
...
}

<second thread>
// Somewhere in the code, wait for the main form to close

Application.Run(applicationContext); // same app context created in main()

re: Keeping your UI Responsive and the Dangers of Application.DoEvents

jfoscoding — Tue, 16 Aug 2005 20:32:21 GMT

Vladimir: I would hesitate to pass the same application context to a different thread - while I dont know of any issues offhand, it was not designed to be thread-safe: e.g. no one's taking locks at appropriate times.

It's probably safer to roll your own application context here for the second thread.

Keeping your UI Responsive and the Dangers of Application.DoEvents

Link Blog — Fri, 19 Aug 2005 01:06:58 GMT

jfo's coding : Keeping your UI Responsive and the Dangers of Application.DoEvents
Whats the difference...

Starting an application without showing a form

jfo's coding — Wed, 24 Aug 2005 17:42:47 GMT

There were a lot of good comments/questions about keeping your UI responsive, if you're interested in...

Articles as seen on jfo's coding

jfo's coding — Thu, 01 Sep 2005 02:27:24 GMT

Custom PaintingPainting best practices ComboBox OwnerDrawLayoutDock layout/Using the Splitter control...

A Nifty Comment Toggling Technique

Craig : Geek, IBlogger — Wed, 07 Sep 2005 20:50:01 GMT

When reading someone else's blog (even when searching for the answer to a specific problem) occasionally...

Application.DoEvents

Ricky Tan, .NET Framework Client Team — Sat, 30 Sep 2006 02:53:43 GMT

While doing the Vista Test Pass, I noticed a lot of timing and synchronization issues in the tests, and...

Phil Bernie Consulting » Disabling MDAs (Managed Debugging Assistant)

Phil Bernie Consulting » Disabling MDAs (Managed Debugging Assistant) — Sat, 21 Jul 2007 08:11:24 GMT

PingBack from http://blog.pnbconsulting.com.au/?p=54

Intel?? Software Network Blogs » Parallel FX & Threading for newbies (like me.)

Intel?? Software Network Blogs » Parallel FX & Threading for newbies (like me.) — Thu, 10 Jan 2008 01:04:53 GMT

PingBack from http://softwareblogs.intel.com/2008/01/09/parallel-fx-threading-for-newbies-like-me/

Windows » jfo’s coding : Keeping your UI Responsive and the Dangers of…

Fri, 09 May 2008 07:03:06 GMT

PingBack from http://windows.wawblog.info/?p=13087