Question

I have a multi-threaded Delphi 6 Pro application that I am currently working on heavily. If I set a breakpoint on any code that runs in the context of the Main thread (VCL thread) I don’t have any problems. However, if a breakpoint is triggered on any code in one of my other threads, after I continue the application from the breakpoint, all repaints to the VCL components on the main thread (including the main form) don’t happen anymore. The application isn’t dead because other background code keeps running, just the main thread. It’s as if the windows message dispatcher has been corrupted or rendered dormant.

Note, in this application I allocate my own WndProc() via allocateHwnd() on the main form because I need to catch certain registered messages. From that WndProc() I dispatch any custom messages I handle and if the current message is not handled by my code, I pass the message on by calling the main form’s inherited WndProc(). If I do handle the current message I simply return from my WndProc() with Msg.Result set to 1 to tell the dispatcher that the message was handled. I can’t simply override the TForm WndProc() instead of allocating my own WndProc() because for some reason the Delphi VCL does not pass through registered messages instantiated with the Windows API RegisterWindowMessage() call.

Has anybody experienced this in similar context and if so, what did you do to fix it?

— roscherl

Answer 1

Since you call AllocateHWnd, that means you’ve created another window. You mustn’t just take the messages that were addressed to that window and forward them to your form’s window. Doing that, you’re bound to screw things up in your program, although I’m not sure exactly how. Painting problems sound plausible. You should make sure it’s really just painting problems and not that your main thread is still suspended. The debugger should be able to tell you that. (You should call DefWindowProc to make your allocated window handle messages you’re not prepared to handle yourself. And returning 1 doesn’t tell the dispatcher anything; the dispatcher doesn’t care — whoever called SendMessage wants to know the result.)

I promise you that forms are completely capable of receiving registered window messages. Override WndProc or assign a new value to the WindowProc property (and remember to save the old value so you can call it after handling your own messages). The source of your problem lies elsewhere.