I use multiple UI threads for just that scenario. Main reason: I can have multiple modal dialogs and they are only modal to one main window at a time. Office is a bad example of an application where modal dialogs in one window block all the windows of the specific application...
Cheers David > -----Original Message----- > From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of > Matthew Adams > Sent: Wednesday, May 29, 2002 4:27 PM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] Putting bits of UI on a secondary thread? (was Re: > [DOTNET] Modeless WinForms Bug) > > Thinking about it, I guess one possible application would be a > multiple-window SDI type application where you wanted several, > independent top-level peers, but didn't want to start multiple > processes? > > Matthew > > -----Original Message----- > From: dotnet discussion [mailto:[EMAIL PROTECTED]] On Behalf Of > Chris Sells > Sent: 29 May 2002 16:10 > To: [EMAIL PROTECTED] > Subject: [DOTNET] Putting bits of UI on a secondary thread? (was Re: > [DOTNET] Modeless WinForms Bug) > > > As an aside, a quick experiment reveals that all appears to be fine if > > you start the message pump on the worker yourself (with > > Application.Run()), but it is still slightly rude, as that pool thread > > will then have a message queue created for it that may not have > existed > > before. > > I don't know why that's rude. No thread has a message queue until > someone > starts looking for or posting messages, even the main thread. It would > be > more rude if a console app had a message queue w/o ever needing one. > > I've had no problems running different bits of a UI on multiple threads, > so > long as I obey the rule of thread affinity for controls, but I have yet > to > find a reason to put bits of UI on anything but the main thread. Since > the > UI operations are already segmented carefully into little bits of work > in > event handlers, I haven't yet been able to motivate the need to have UI > running on secondary threads. My prefered model is to spin off long > running > operations onto threads from the thread pool via asynch delegates and > use > message passing between the UI thread and the worker threads to > communicate > work/results and eliminate the need for synchronization. > > Chris > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, > or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
