Question

http://msdn.microsoft.com/en-us/library/zyzhdc6b.aspx

Executes the specified delegate on the thread that owns the control’s
underlying window handle.

According to the MSDN article, a thread can own other handles.

My best guess, is that the thread is some special super kernel object, with a handle that other handles can refer too?

like:

Handle | Thread-Handle-Reference

3201 | 20

4882 | 20

4827 | 7

Answer 1

In these terms, yes.

Basically, behind the scenes of the Windows GUI is a “message loop”, which is a two-way communication between the Windows OS (which knows about the mouse, keyboard and other input hardware) and your program (which doesn’t need to know the specifics, but does need to be responsive to user input within your app based on these input devices). There is a thread in your program (the main program execution thread, usually) that maintains this loop, listening for messages coming into the program from Windows, and parsing and passing messages to the various GUI controls and other code objects. This “GUI messaging thread” knows and maintains references to all the window handles of all GUI objects in your program; it must, because if it doesn’t, it cannot pass messages to them and will not be listening for messages from them.

It is generally a bad idea to try to do something to a GUI control instance from outside the thread that is connected to the message loop. By doing so, it is possible for the control or sub-controls owned by the control to become detached from the message loop, or to never be attached in the first place. The “GUI message thread” then no longer knows about that control, and is no longer passing messages to or from it. Those controls become “rogue”; neither the program nor Windows can tell the control to move, redraw itself, or go away. The only thing Windows can do at that point to “control” the window is to shut down the process that owns it, thus terminating your entire program.

To avoid this, GUI controls have a special method “Invoke” (and an asynchronous cousin “BeginInvoke”) designed to be used from outside the GUI messaging thread. These methods basically send a message from the window to itself through the Windows message loop that causes the main GUI thread to execute the delegate specified in the Invoke call. By doing so, any new GUI objects created within or as a result of that code will be known to the main GUI thread.