>> 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.
Actually, that particular restriction is. In fact it's arguably not
accurate to describe it as a restriction. It's simply how it works -
Windows delivers all MSG for a particular HWND on that HWND's thread's
message queue.
Win32 positively does allow you to *send* messages from a different
thread. In that respect, it's less restrictive than Windows Forms - the
"you must only use a control from the thread that created it" rule is a
Windows Forms restriction.
It's just that if you send or post a message from a different thread,
Windows simply puts the message into the message queue for the target
HWND's thread. And if you're using SendMessage, the sending thread will
then be blocked until the target thread's message pump picks up the
message and handle it. (I.e. SendMessage behaves differently when you
call it on a different thread. If you call it on the target HWND's UI
thread, it bypasses the message queue entirely.)
As to the multi-UI thread rule, I once asked Jessica Fosler about this.
She was a PM on the Windows Forms team, and was therefore in a good
position to give a definitive answer. The context in which the question
was asked was when I was writing the threading appendix of Chris Sells'
and my WPF book. Chris was under the (mistaken, it turns out) impression
that multiple UI threads were illegal in Windows Forms. So we were
asking the Windows Forms team for an official answer to put something in
print. (Not the same as public documentation I know, but this is the
most definitive answer I know of.)
She said that Microsoft supports but discourages the use of multiple UI
threads in Windows Forms apps.
So you're definitely allowed more than one UI thread. (And the chat
Stoyan quoted from seems to support this. And while I have a lot of
respect for Nick Paldino, I'm afraid he's definitely wrong if you've
quoted him correctly - Win32 itself has definitely always allowed
multiple UI threads. Internet Explorer and Windows Explorer both depend
on this.) However, there was a restriction surrounding AppDomains.
Annoyingly, I can't actually remember what that restriction was... (It
wasn't relevant to what I was writing for the book.) I know you're
definitely not allowed to try and have a single Win32 thread participate
in UI in two different AppDomains. But it may have been more restrictive
still - I can't actually remember whether you're allowed to have UI in
multiple appdomains if you use multiple threads to do that. But if it's
not permitted, it's an Appdomain restriction, not a multi-UI-thread
restriction.
--
Ian Griffiths
-----Original Message-----
From: Peter Ritchie
> 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
