Delphi 6: breakpoint triggered when a non-VCL thread shuts down

Question

I have a multi-threaded Delphi 6 Pro application that I am currently working on. If I set a breakpoint on any code that runs in the context of the main thread (VCL thread), I have no problem. However, if the breakpoint is triggered by any code in one of my other threads, after I continue the application from the breakpoint, all redraws to the VCL components in the main thread (including the main form) no longer occur. The application is not dead because another background code continues to work, only the main thread. It is as if the Windows Message Manager was damaged or turned out to be inactive.

Please note: in this application, I highlight my own WndProc () via allocateHwnd () in the main form, because I need to catch certain logged messages. From this WndProc (), I send any custom messages that I process, and if the current message is not processed by my code, I pass the message, invoking the main view inherited by WndProc (). If I process the current message, I simply return from my WndProc () with Msg.Result set to 1 to tell the dispatcher that the message has been processed. I cannot just override TForm WndProc () instead of highlighting my own WndProc (), because for some reason Delphi VCL does not go through registered messages created with the Windows API call RegisterWindowMessage ().

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

- roscherl

Answer 1

Since you call AllocateHWnd , it means that you created another window. You should not just send messages that were addressed to this window, and forward them to the form window. By doing this, you will definitely get involved in your program, although I do not know exactly how to do this. Problems with drawing look plausible. You have to make sure that these are really just problems with the painting, and not that your main thread is still paused. The debugger should be able to tell you this. (You must call DefWindowProc to make your selected window descriptor messages that you are not ready to process yourself. And return 1 tells the dispatcher nothing, the dispatcher doesn't care — the one who called SendMessage wants to know the result.)

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

Answer 2

UPDATE: I am not saying how I got past the problem, this is a good solution. I need to take notes from Rob Kennedy and do the refactoring. However, to overcome the problem at the moment, I gave the stream in which it belongs to Window and WndProc (), and to the top of the stream. In the Execute loop, I have PeekMessage (), and the loop with calls to TranslateMessage () and DispatchMessage (). I no longer have the problem of setting breakpoints in the stream, but obviously this recipe for the WndProc () methods indicates a structural problem in my code. I would like to add this answer to fill the discussion. I hope that as soon as I attach Rob's suggestions, when I clean my WndProc () methods in the appropriate forms, especially in the main form, I can get rid of this new WndProc () that I just added to the stream.

Robert.