> I believe it gets down to one message pump handling > UI messages--since each message pump needs to be on > it's on thread there can be only one UI thread.
Win32, and WinForms, both *definitely* support having more than 1 UI thread per process. You need to "do the right thing" in WinForms, which means doing basically the moral equivalent of what you did in Win32 to get this to work. This is a 100% supported scenario for .Net and WinForms. The short list of what you need to do is: 1) Make sure you are pumping messages on all of your UI threads. This means calling Application.Run, which is the easiest way to pump messages (correctly!) in managed code. 2) Understand and conform to the requirements about interacting with WinForms objects. Basically, if you're not running on the UI thread on which the object was created, you can't touch the object. The only exceptions are well-documented and supported: You can use BeginInvoke (asynchronous, equivalent to PostMessage) or Invoke (synchronous, equivalent to SendMessage) from threads other than the UI thread for a control in order to execute delegates on the correct UI thread. You can also call CreateGraphics to create a Graphics object to draw on the control; however, I'd discourage this. 3) When you create threads, declare their apartment type as soon as you can. I believe (but am not positive) that you can modify the thread's ApartmentState property *before* starting the thread. This guarantees that nothing can accidentally set the apartment state "behind the scenes". This can happen sometimes in class constructors (.cctor / static foo() ), which can be maddenlingly difficult to track down. I'm not claiming that WinForms is perfect, but it certainly does support multithreaded UI apps, and it does support multiple UI threads per process. Interaction with app domain may introduce some new wrinkles, as some have discovered. I would suggest verifying your design within a single app domain, then checking it with multiple app domains, in order to determine whether the problem you're encountering is related to app domain boundaries or is a bug in your app code. Be really, really careful about interacting between UI threads and worker threads. It's hard to get this right in Win32, and it's still, for the most part, not easy to get it right in WinForms, because WinForms still runs within the same Win32 architecture, and so has basically the same architecture and constraints. For the most part, WinForms is a wrapper for Win32 (USER32.DLL and friends). You'll also have to deal with all of the classical deadlock / message starvation problems, if you're communicating between 2 UI threads. Again, this is standard Win32 stuff (painful at times, but not new / unique to WinForms). In .Net 2.0, there is a very useful class, BackgroundWorker, which handles getting a lot of the details of correctly starting, communicating with, and receiving notification of the termination of background tasks. It isn't perfect, but it's a big improvement. Note that you *still* have to deal with cross-thread synchronization and you still have to avoid touching UI objects from non-UI threads. I realize the OP is dealing with multiple UI threads, but from the point of view of Win32/WinForms, 2 UI threads are about the same as 1 UI thread and 1 worker thread. By the way, as a self-introduction, I'm a Microsoft developer, and I've worked with many large, complex Win32 and WinForms apps. I'm *not* speaking for the company -- I'm posting on my home account, and I'm not a member of the CLR team. So I'm just trying to be helpful here. The main thing is that Win32 and WinForms definitely support multiple UI threads per process -- it's a crucial scenario, after all! And the usual caveat applies -- just because it's supported doesn't mean there aren't bugs, or corner cases that are surprising or difficult to deal with. Implicit property evaluation is definitely troublesome, if you're looking at stack frames that have access to references to UI objects on other threads. To the OP -- Can you be more specific about what problems you're encountering? I'll do what I can to debug over SMTP. -- arlie -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Peter Ritchie Sent: Wednesday, July 19, 2006 8:32 AM To: [email protected] Subject: Re: [ADVANCED-DOTNET] VS2003 Debugging Issues with Multiple UI Threads Having a program manager, whose background is technical writing, reply with "You can have multiple UI threads" to a question asking about "more than one message loop per process" doesn't give me a warn and fuzzy when you've got seasoned developers like MVP Nicholas Paldino saying otherwise: "For any process, you are only supposed to have one UI thread. Doing otherwise will have unpredictable results. This has been the model for Windows programming for as long as it has been around." [1] You can certainly have more than one message loop or message pump per process, but that's not the same thing as having more than one UI thread. I believe it gets down to one message pump handling UI messages--since each message pump needs to be on it's on thread there can be only one UI thread. [1] http://www.thescripts.com/forum/thread228141.html On Wed, 19 Jul 2006 09:43:30 +0300, Stoyan Damov <[EMAIL PROTECTED]> wrote: >Host: MarkRi (Microsoft) >Q: So it would seem to me that it is possible and that I can have more >than one message loop per process. However, is this recommended? If so, >what do I need to look out for? > >A: You can have multiple UI threads per process, but you must call >Application.Run() on each thread. You can also call ShowDialog() >instead of Run(). ShowDialog() creates a message loop. The tricky part >is that we don't support having those UI components interacting >natively -- you'll have to do your own marshalling using >Invoke/BeginInvoke. =================================== 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
