Question

I have a Delphi 6 application that is heavily multithreaded. I have a component I created that descends from TWinControl. When I first built it, I used a hidden window and it’s WndProc to handle messages, allocated with AllocateHwnd(). Recently I started cleaning up the WndProc’s in my code and decided to remove the auxiliary WndProc(). I changed the component to override the base class WndProc() method instead and do its custom windows message handling from there. In that WndProc() I called the inherited handler first and then processed my custom messages (WM_USER offsets), setting the message Result field to 1 if found one of my custom messages and handled it.

One important note. I put a line of code at the top of the WndProc() override that throws an Exception if the current thread id is not the VCL main thread. I wanted to make sure that the WndProc() only executed in the context of the main VCL thread.

After doing this and running my program I ran into something that seems truly bizarre. I ran my program as normal and did various tasks without error. Then, when I went to a TMemo control that resides on the same page as my TWinControl descendant. If I clicked inside that TMemo control the main thread check in my WndProc() override triggered. I had a breakpoint set on it and when I went to the call stack, there was nothing on it above my WndProc() override.

As far as I can tell, and I’ve double checked, I do not make explicit calls to the WndProc() override. That’s not something I’d ever do. But given that my TWinControl component would have been created on the main VCL thread like all the other components, I can’t fathom how the WndProc() override would ever execute in the context of a background thread, especially only when a UI action like a mouse click would happen. I understand how my WndProc() is tied to the TMemo control since all child windows hang off the top level window WndProc(), at least that’s my understanding. But since all the component windows would have been created on the main VCL thread, then all their message queues should be executing in that context too, right?

So what kind of a situation could I have created to make my WndProc() run, and only sometimes, in the context of a background thread?

Answer 1

There are two ways a main thread component’s WndProc() method could be called in the context of a worker thread:

1. the worker thread directly calls into the component’s WindowProc property, or its Perform() method.

2. the worker thread has stolen ownership of the component’s window through unsafe usage of the TWinControl.Handle property. The Handle property getter is not thread safe. If a worker thread reads from the Handle property at the exact same moment that the main thread is recreating the component’s window (TWinControl windows are not persistent – various runtime conditions can dynamically recreate them without affecting the majority of your UI logic), then there exists a race condition that could allow the worker thread to allocate a new window within its own context (and cause the main thread to leak another window). That would cause the main thread to stop receiving and dispatching messages within its context. If the worker thread has its own message loop then it would receive and dispatch the messages instead, thus calling the WndProc() method in the wrong thread context.

I find it odd that no call stack is being produced, though. There should always be some sort of trace available.

Also, make sure the MainThreadId variable (or whatever you are using to track the main thread) is not simply getting corrupted by accident. Make sure its current value is consistent with its initial value from startup.

Another thing you should do is name all of your thread instances in the debugger (this feature was introduced in Delphi 6). That way, when your thread validation gets tripped, the debugger can show you the exact name of the thread context that is calling your WndProc() method (even without a call stack trace), then you can look for bugs in the code for that thread.