PostMessage problem

PostMessage problem
For a long time, I've been using AllocatehWnd in the main thread to create handles for passing messages from background threads to the foreground thread.  

All the handles are created in the same location (during main thread startup), connecting to different handler procedures.  All messages are wm_user + unique number (from 1 to 140)

Recently, this stopped working for 3 of 4 handles, and I can't for the life of me figure out why?  

The only messages I see, is a value of 28 (which is wm_ActivateApp) and it arrives on startup only) - and then I see one of my other registered messages from a specific background thread (wm_user + 121).

For the other threads, I see the postmessage being called, with the right handle and the right message - but it never arrives in the registered handler.

I've tried moving the message from wm_user + 1 to wm_user + 151 - in case something else was eating them.  No joy.

I've tried using only one handle, and calling all of the four handler methods from the common registered handler.  The same results.

Each handler do call DefWindowProc.  Can it be a component vendor that inserts a handler, but which fails to call DefWindowProc?

I need suggestions for possible causes, or for how to best drill down to the core of the problem, because I am stumped!

Comments

  1. I forget, but doesn't TApplicationEvents.OnMessage hook the main message pump? If so, use it to see if you see them there or not. Just a random thought.

    ReplyDelete
  2. Asbjørn Heid - Using TApplicationEvents, it was trivial to find the spanner in the works: an infinite loop in a message handler.

    ReplyDelete
  3. Lars Fosdal Infinite loops, fun for the whole family :)

    ReplyDelete
  4. Just upgrade your hardware so it'll run the infinite loops faster. ;)

    ReplyDelete
  5. The reason that it was so hard to spot was that the infinite loop was throttled by a different mechanism (i.e. no CPU spike), and that the app have no UI.  I'd be pulling my hair, if it wasn't so short...

    ReplyDelete

Post a Comment