4 ms·

I had this bug once about 10ish years ago when I was still a windows dev. Creating a 2nd window on a thread with a window already but then pumping it's main loo

I had this bug once about 10ish years ago when I was still a windows dev. Creating a 2nd window on a thread with a window already but then pumping it's main loop on a background thread can cause this. If you do that the loops get hooked to each other regardless of the thread pumping it. The child window has to wait until the parent window forwards the event for the second thread to pop it off. A mouse move will send a WM event and keep the child windows loop on the other thread spinning. My WM_TIMER on the child window was stuck as well. It happened to me because I had a hidden window on the background thread to get WM events for USB disconnect and reconnect messages from the system. The bug report was funny. "Connecting USB data collection probe doesn't work unless the user moves the mouse after connecting." and the follow up bug "Data collection only works when moving the mouse."

asveikau 13y ago
The rule of thumb as I always heard it is that a window is "owned" by the thread that created it. You can send and post messages from a different thread, but do much else and you're asking for trouble. (And Send instead of Post is often problematic since it will block until the target thread processes it.) Draining the message queue from a thread that doesn't own it makes absolutely no sense to me ... Does that actually work? Wouldn't you see the messages on the original thread's pump too? I thought the way it worked is each thread with ui objects has a queue, and SendMessage et al. will insert into the owning thread's queue. It took me a while to parse what you are saying, did you pass the hwnd into GetMessage from the other thread and that somehow convinced it to peek at another thread's queue?
- zbowling 13y ago
  Pumping from the wrong thread is undefined behavior and it results in the bug above. It's a fairly common bug.
- pea 13y ago
  COM hates MTA threading, most of the Office object model actually insists on STA single-threads sitting in the main UI thread to even work (i.e. you cannot use BackgroundWorker() )! Some guy @ MS even released this byzantine code to deal with the situation (http://blogs.msdn.com/b/andreww/archive/2008/11/19/implementing-imessagefilter-in-an-office-add-in.aspx?Redirected=true http://blogs.msdn.com/b/andreww/archive/2008/11/19/implement...) which unfortunately doesn't work. It's completely nuts how bad the object model is.
  - overgard 13y ago
    As much as I make fun of java developers for over complicated solutions, I've never quite seen anything as over-engineered and byzantine as COM. I remember at my last job we had legacy COM objects that inherited from about 5-7 different templated objects, and that was... normal. COM is the worst. I actually like windows as a user, but I'm amazed that it won as much developer mindshare as it did considering how much the win32 api sucks. It's brutal.
    - lafar6502 13y ago
      But COM has been adopted by Linux world too, and renamed to Bonobo. In fact, if you throw away all VB-specific stuff, COM and its C++ implementation is a great programming exercise and is imho quite elegant.
      - Shog9 13y ago
        "The VB stuff" is pretty much all you get when you work with MS-Office. Don't know that I'd call COM "elegant", but you could probably do worse for a language-agnostic object system. Funny enough, I never really "got" COM until I sat down and read up on Bonobo. Someone had a really accessible explanation for Monikers that would've saved me so much hair-pulling if I'd had anything similar for the Windows equivalent.
    - frik 13y ago
      Similar to COM, are (beside OLE, DCOM, ActiveX) Gnome's "Bonobo" (component model) [1], KDE's KParts, Mozilla's XPCOM and CORBA. Apple choose KHTML over Gecko for it's Webkit fork [2] because of the various cons of such component models. [1] Bonobo is officially deprecated: http://en.wikipedia.org/wiki/Bonobo_(component_model) http://en.wikipedia.org/wiki/Bonobo_(component_model) [2] http://en.wikipedia.org/wiki/XPCOM http://en.wikipedia.org/wiki/XPCOM
      - overgard 13y ago
        I remain convinced that C++ warps peoples minds into things like this :-). I'll go out on a limb and say that pretty much ALL of those things are horrible.

asveikau 13y ago

The rule of thumb as I always heard it is that a window is "owned" by the thread that created it. You can send and post messages from a different thread, but do much else and you're asking for trouble. (And Send instead of Post is often problematic since it will block until the target thread processes it.) Draining the message queue from a thread that doesn't own it makes absolutely no sense to me ... Does that actually work? Wouldn't you see the messages on the original thread's pump too? I thought the way it worked is each thread with ui objects has a queue, and SendMessage et al. will insert into the owning thread's queue. It took me a while to parse what you are saying, did you pass the hwnd into GetMessage from the other thread and that somehow convinced it to peek at another thread's queue?

zbowling 13y ago
Pumping from the wrong thread is undefined behavior and it results in the bug above. It's a fairly common bug.
pea 13y ago
COM hates MTA threading, most of the Office object model actually insists on STA single-threads sitting in the main UI thread to even work (i.e. you cannot use BackgroundWorker() )! Some guy @ MS even released this byzantine code to deal with the situation (http://blogs.msdn.com/b/andreww/archive/2008/11/19/implementing-imessagefilter-in-an-office-add-in.aspx?Redirected=true http://blogs.msdn.com/b/andreww/archive/2008/11/19/implement...) which unfortunately doesn't work. It's completely nuts how bad the object model is.
- overgard 13y ago
  As much as I make fun of java developers for over complicated solutions, I've never quite seen anything as over-engineered and byzantine as COM. I remember at my last job we had legacy COM objects that inherited from about 5-7 different templated objects, and that was... normal. COM is the worst. I actually like windows as a user, but I'm amazed that it won as much developer mindshare as it did considering how much the win32 api sucks. It's brutal.
  - lafar6502 13y ago
    But COM has been adopted by Linux world too, and renamed to Bonobo. In fact, if you throw away all VB-specific stuff, COM and its C++ implementation is a great programming exercise and is imho quite elegant.
    - Shog9 13y ago
      "The VB stuff" is pretty much all you get when you work with MS-Office. Don't know that I'd call COM "elegant", but you could probably do worse for a language-agnostic object system. Funny enough, I never really "got" COM until I sat down and read up on Bonobo. Someone had a really accessible explanation for Monikers that would've saved me so much hair-pulling if I'd had anything similar for the Windows equivalent.
  - frik 13y ago
    Similar to COM, are (beside OLE, DCOM, ActiveX) Gnome's "Bonobo" (component model) [1], KDE's KParts, Mozilla's XPCOM and CORBA. Apple choose KHTML over Gecko for it's Webkit fork [2] because of the various cons of such component models. [1] Bonobo is officially deprecated: http://en.wikipedia.org/wiki/Bonobo_(component_model) http://en.wikipedia.org/wiki/Bonobo_(component_model) [2] http://en.wikipedia.org/wiki/XPCOM http://en.wikipedia.org/wiki/XPCOM
    - overgard 13y ago
      I remain convinced that C++ warps peoples minds into things like this :-). I'll go out on a limb and say that pretty much ALL of those things are horrible.