You can definitely do it and it is not restricted in any way by the OS or most other platforms (excepting VB and the like). IE does it when you "open new window", Word does it per document IIRC, and there are other examples. Any thread that wants to have a UI can do so by simply following the requirements of pumping messages, STA for COM, etc. The only problem is that the potential for screw ups by the programmer goes WAY up since you have to be very careful about how each thread is used.
Russ -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Peter Ritchie Sent: Wednesday, July 19, 2006 7:21 AM To: [email protected] Subject: [ADVANCED-DOTNET] UI Thread count per process restrictions [was Re: VS2003 Debugging Issues with Multiple UI Threads] I've changed subjects, I don't want Michael's thread to get hijacked... J., define what you mean by "can"... If you mean "it will compile"; that's not an indicator of correctness. ...I "can", for example, write a WinForms app. where my main method has [MTAThread]. If all I'm doing is showing a form and simple controls, there will be no problems. If I want to use ActiveX controls (including common dialogs, or more specifically: communicate with an object on an STA thread) there will be errors. That's why it's not supported. ...I "can" write a background thread that communicates with WinForm controls and it will work most of the time. If the application is sufficiently simple, it will work all of the time. But, it's not a good idea, and it's certainly not supported. What I'm trying get to the bottom of is, recommended UI thread (aka window message pump or window message loop) count restrictions. Nobody really seems to know for sure, one way or another. It's pretty clear that one UI thread is supported, what's not clear is whether multiple UI threads per process are supported. Many of us have written code that works until the circumstances change and it begins to fail; only then, realizing that a recommendation was not followed (because it was not well known). That's really what the MDAs are all about in Visual Studio 2005. Yes, many people have written applications with more than one UI thread (just like MTA WinForms apps, buffer overflows, catch(Exception), defined protected members in sealed classes, implemented public readonly array fields, PInvoked a method with the wrong parameter types, used GC.Collect, called StreamWriter.Dispose without calling StreamWriter.Flush/Close, etc.- -all of which have been done by at least on Microsoft employee) but, just like aforementioned practices, doesn't mean it's supported. For the moment, I'm airing on the side of caution: restricting my UI threads to one per application--I know that is supported. On Wed, 19 Jul 2006 09:20:02 -0400, J. Merrill <[EMAIL PROTECTED]> wrote: >At 01:08 AM 7/19/2006, Peter Ritchie wrote (in part) >>I'm of the opinion that Windows only supports one UI thread per process. > >If multiple AppDomains can exist within a single process, and each can >be hosting an app with a UI, doesn't that suggest the opposite? > >I'm not saying that's a definitive answer, but it certainly points the other way -- or am I missing something? =================================== This list is hosted by DevelopMentorR http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
