Can you please confirm if a button click go though TApllication.ProcessMessage ? or an event triggered like TForm.OnShow went through that ? because it doesn't,
ProcessMessage in TApllication ..
Well, as you said i am lacking understanding of stack working and
VCL design, who knows may be there are, i must simply don't know.
So please forgive me for wasting your time.
The mouse button down and up messages are posted messages (by the
OS), are retrieved (GetMessage/PeekMessage
API) and processed (DispatchMessage
API) by ProcessMessage. TButton is a wrapper aound the Windows BUTTON control and that reacts to the dispatched mouse messages by sending (not posting) a BN_CLICKED notification to its parent. The
VCL reflects that back to the TButton control and there it fires the OnClick event. So if you examine the call stack from a breakpoint in the OnClick event handler you do not see ProcessMessage on it since there is a heap of
OS stuff in between. It is similar for a form's OnShow, the message triggering it is send (by the
OS), not posted, so it does not go through ProcessMessage.
Most posted messages are created by user action (mouse, keyboard), timers, or
OS activities that do not require immediate response, e.g. paint requests. Those are retrieved and distributed by ProcessMessage. But there are a lot of other messages that are directly send to the window/control they are for, and those do not go through ProcessMessage.
Messages are the fuel that drives the Windows UI layer and a lot of other parts of the
OS. To get a basic understanding of this stuff you need to work your way through one of the older "Programming Windows" books by Charles Petzold (not the newer ones targeted at .NET/C# programmers). If you survive you will have a much deeper appreciation for what the
VCL shields us from.
To get a feeling for the message processing in the
VCL you may want to read an old article on key processing I wrote an eon ago:
A Key's Odyssey.