> When I wrote "can" I meant "Windows, the CLR, and the .Net
> Framework permit" -- and I just don't see why MS would have
> built them to permit this if there were an inviolable Windows
> rule about multiple UI threads in a process.
It's not without precedence that Windows assumes programmers know all
unsupported actions and let them do what they want, assuming they do
everything correctly. Cross-thread SetWindowsText, for example.
>.Net includes AppDomains in order to allow multiple logical
>processes to be hosted in a single Windows process.
AppDomains are for sub-isolation and enforcing security boundaries, I
wouldn't call them logical processes. A thread isn't restricted to a
particular AppDomain throughout its lifetime--it's only resritced in it
can only be executing in one AppDomain at a time--for example.
>A restriction that I know exists is "the thread that creates a
>window must be the thread that handles all messages sent to
>that window."
Again, that restriction is not inforced by Windows. .NET 2.0 adds some
checks in a few places to keep a programmer from shooting himself in the
foot and throwing exceptions, like cross-threaded calls to
Control.set_Text.
>That means that any thread that creates GUI objects (=windows) must
>have a "message pump" so that it can receive the messages. It
>doesn't say anything about how many threads in a process are
>allowed to create GUI objects (and have message pumps etc).
You can't infer from that, and the lack of documentation for either
scenario, that multiple UI threads are therefore supported. There's been
much precendent from Microsoft with sample code that's simply wrong, or
incorrect documentation. One could argue the existance
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Compatibility exists in
part to compensate for legacy programs that "did it by book" but the book
didn't mention certain Windows assumptions/restrictions--or, at least to
compensate for the logic "Windows let me do it so it must be the correct
way of doing it".
>If Windows didn't support it, wouldn't it fail calls to CreateWindow
>from subsequent threads? ("subsequent threads" meaning "threads
>other than the one that made the first CreateWindow call in the
>process, if there are any existing windows still owned by that
>thread.")
That would make it consistent with cross-thread calls of SetWindowText--
which also don't fail. Not to mention, you can call CreateWindow on a
thread that has no message pump, Windows doesn't care to check (like
making sure WM_CREATE is processed on the same thread within a reasonable
amount of time).
===================================
This list is hosted by DevelopMentor® http://www.develop.com
View archives and manage your subscription(s) at http://discuss.develop.com
