We have a system in which, as a rule, two processes work in one system. One process processes the graphical interface, while others work as a service (although for historical reasons it is not a service, just exe without a visible window).
The two processes conduct IPC mainly through registered messages asynchronously - that is, we use RegisterWindowMessage() in both processes to define a large set of messages that effectively form the API for the server process.
I wrote a hands-free monitoring application that uses SetWindowsHookEx() to monitor and display message queues of both processes and provide some level of decoding of how to use the API and how to distribute notifications to the GUI process (each individual window can directly subscribe to notifications from the server) .
Thus, in both directions there is a large number of messages, so I have filtering and the total score, etc., so I can focus on a specific activity. All this can be done without affecting the live code, which is good.
All this works well, but now it would be very useful to "mark" the message coming from the GUI so that I can track the same message when it is processed by the server. This would be extremely useful for debugging and diagnosing systemic problems, but I cannot find a clean way (in fact, I can not find any way!) To do this without adding such support to our registered message API that would be very work and carries more risk than I like right now. This is complicated by the fact that the server pre-processes some messages and then returns PostMessage() to itself to perform the action, so the original message may be lost.
Has anyone here solved this problem? If so, can you give me some pointers? If not, are there any documented or undocumented ways to add a small block of data to a Windows message and then receive it? I looked at SetMessageExtraInfo() , but it looks like a queue, not a message.
Roger rowland
source share