I am not sure what "supported" means, but I have written a demo package that puts up four independent .Net windows forms that each run on a separate thread and each have a separate message pump. This was to support a presentation on threading. Now this package was not extensively tested nor was it used for any great length of time. I have no idea of how robust the code is or how valid the approach is. But it can be done. Given what understanding that I have of how windows handles screen events, I do not see any conceptual reason to believe that the whole thing will fall apart because of the multiple message pumps. Based upon my personal experience, it is an order magnitude more likely that some of the logic on one thread will do something that will cause problems by performing some cross-thread operation that will not fail immediately but will lie in wait, festering, until the maximum pain can be inflected on the poor unsuspecting user. Just my "contribution" to the community. Jon Stonecash
> Date: Wed, 19 Jul 2006 15:17:08 -0700> From: [EMAIL PROTECTED]> Subject: Re: > [ADVANCED-DOTNET] UI Thread count per process restrictions [was Re: VS2003 > Debugging Issues with Multiple UI Threads]> To: > [email protected]> > I just checked this system (XP sp2 > with IE6) and it works just as I> remember. Ever "open in new window" > results in one or more new threads. I> didn't attach a debugger or other > tools to verify or disprove the rest, I'll> leave that as an exercise for the > reader. <grin> But, your right about> Word. Maybe it was an older version > I'm thinking of, maybe I'm delusional.> > > I'm on semi-vacation at the > moment, which is why I actually had time to dig> through accumulated emails > and even take time to comment on one that caught> my eye. But I lack > motivation to go digging for document references for an> on-line debate that > I can't easily create a search query to produce. I can> only say that I've > programmed for WinX for since Win16 and the very> beginnings of Win32 in the > days of massive switch statements. 95%+ of that> work being in C++ including > a fair bit of low level stuff. Which of course> does not lend me any > credibility, but is just a way of leading toward saying> that in that time > I've worked on and observed programs from both MS and> others running more > than one UI thread in a process. There is nothing> magical about a "UI > thread", it's just a thread using user32 services. It> get's a message > queue, and pumps messages, end of story. If you don't buy> that, oh well...> > > Think of it this way. It's no different than having any number of STA> > threads in a given process with its own hidden window and message pumps> > inside the channel or otherwise. Is it your position that we can only have> > on STA per process? Or is it your position that the windows just can't be> > visible? <grin>> > Anyway, have fun with your debate, I'm going to do other > things besides sit> in front of a computer now that I got my computer "fix" > for the day...> > Russ> > -----Original Message-----> From: Discussion of > advanced .NET topics.> [mailt =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
