tags:

views:

638

answers:

5

I have a Windows Forms (.NET) application that can have multiple documents open simultaneously.

It would be convenient to have each document (form) running its own event loop. With brief experimentation, starting several event loops in their own STA threads seems to work. Is there any reason why this is a bad idea?

A: 

Just be careful with accessing the GUI elements from the threads.

Kevin
A: 

Modeless forms might be more appropriate for your purpose. Use form.Show() instead of form.ShowDialog().

Michael L Perry
+1 indeed. Doesn't everybody do it like this? You can show as many forms as you like in this way.
Wim Coenen
We already have multiple windows with modeless forms on a single UI thread. There are certain problems with this approach that we'd like to overcome (we want some dialogs to be modal for an individual window but not for all open documents for example).
fuzzyman
+1  A: 

It might be smarter to use an MDI (Multiple Document Interface) container and child forms. In this case, each document would be in its own form, which technically means each document has its own message queue.

OwenP
MDI containers are goddawful from a user point of view.
fuzzyman
MDI is REDUNDANT from a user POV since the Desktop IS an MDI container.
Peter Wone
Why all this hate against MDI?? MS Office apps are all MDI.
DJ
Word doesn't use MDI. MDI makes Excel painful to use - try having two open documents on two different monitors...
fuzzyman
For the last couple of revisions Office apps have been multi-SDI (which means they let the desktop serve as the MDI container). In order to placate people who cannot bear change there is a configuration switch to turn them back into MDI apps, but I have never seen it used.
Peter Wone
A: 

Why do you think you need more than one message loop? One message loop can handle any number of windows.

If you're finding that a long-running operation in one window is capable of hanging the whole app, then the answer is to split out the long-running work into something like a BackgroundWorker, leaving the UI responsive.

Programming with multiple threads, each with their own UI, is much more complicated, because one thread cannot access windows and controls created from another thread.

Tim Robinson
Modal dialogs block the whole application. We *do* need them to block the form (document) they are called from, but not to block the whole application.
fuzzyman
+2  A: 

I think it's perfectly fine do create multiple message loops on different threads. The only thing to watch out for is when dealing with 3rd party UI toolkits, they sometimes store handles as static (instead of ThreadStatic) members and if you have multiple UI threads in your application, it will have problems (in my case, I found that the menu / toolbar keyboard accelerators did not work properly).

One of the big reasons for doing this is if you have modal dialogs that show up on the different modeless dialogs. If you put everything on the same message loop, then if one of the modeless dialogs has a modal dialog, the whole application (all the windows) are blocked until you dismiss the modal dialog.

And, like Kevin was saying, watch out for cross-window (cross-thread) calls. You can use Control.BeginInvoke or Control.Invoke to post delegate calls on the other UI threads.

The other thing to consider is how you will be exiting your process. You will most likely need to keep track of the message loops so you can stop them when you want to close everything out. If you don't care and just want the process to end when all the windows are closed, you can do that too.

Garo Yeriazarian