Which is more or less what Internet Explorer appears to do. Sometimes. Except when it doesn't. (I've never quite worked out what it is that causes it to ignore the settings for launching in a new process or not...)
But anyway, you would only ever need to do this if your UI thread ever went off and did stuff for a long time. In theory a well designed application would never do this, in which case you'd never need more than one UI thread. (After all the user is only going to be using one window at a time.) But you could look on it as an insurance policy against those API calls you never realised could block for seconds at a time... (Or against 3rd party controls.) -- Ian Griffiths DevelopMentor ----- Original Message ----- From: "Matthew Adams" <[EMAIL PROTECTED]> > 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? > > -----Original Message----- > From: Chris Sells > > > 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. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
