To stop at any call to the API function, find it in the implementation
section of Windows.pas (or where the interest function is declared) and set a breakpoint. This applies to functions that you use with dynamic linking of load times. To dynamically link the runtime ( LoadLibrary
and GetProcAddress
), you will need a different method. The variable that gets the result of GetProcAddress
will contain the address you want to split, but I do not know how to set a breakpoint at this address.
Stopping a message in a window is more difficult because messages can be retrieved in many places. Instead, you have to use conditional breakpoints.
To catch most published messages, you can put a breakpoint in TApplication.HandleMessage
on the first line after calling PeekMessage
. Set the condition Msg.Message = x
. HandleMessage
processes messages sent to the main thread message queue for the main Application.Run
message loop, as well as for VCL message loops. Other modal dialogs (e.g. Windows.MessageBox
) will not use it.
Observing sent messages is more difficult because the OS sends them directly to its target window procedures. You will need to set a breakpoint in the window procedure of each window class that interests you. You can get most VCL window classes by setting your conditional breakpoint in Classes.StdWndProc
.
Keep in mind that conditional breakpoints can be very slow. They work as a debugger, placing an unconditional breakpoint there, and when the OS starts it, the debugger takes over, checks the condition and then resumes execution if the condition fails. This may include a lot of overhead, switching between a debugger and your application; programs receive a lot of messages, so if you can find a way to prevent the debugger from interrupting your program to check each one, do it.
If this is not possible for what you are trying to debug, I recommend posting a new question where you describe a problem that you are really trying to solve.
source share