We have developed a DSL tool and what we now want to do is add the ability to record user generated MMI events so that they can be replayed latter for debugging purposes.
We don’t want to log at the mouse and key event level because the display may change between versions of our code. So making use of a WH_JOURNALRECORD hook and likewise the playback version is unsuitable for our application. What we think we need to do is to catch each event at the next stage (where the pump calls the user call-backs).
We have had a look at DSL’s undo/redo mechanism but this seems to record at the transaction stage, which is too late in the cycle to exercise our call-backs.
We had a similar problem a while back but in that case we wanted to extend the pump to deal with an additional event stream. The solution was very simple and is discussed below;
/* Anyone who hooks the message pump will call this & process CLP messages */
/****************************************************************************/
BOOL ClpProcess::ProcessMessageFilter (int code, LPMSG lpMsg)
{
FlushClpMessages ();
return CWinApp::ProcessMessageFilter (code, lpMsg);
}
1.In our earlier work we overrode the CWinApp::ProcessMessageFilter function to add a call to our FlushClpMessages function that then handled CLiP generated events. The code then continued to call the user code as standard. This is the point at which we think we could write the messages to file for subsequent replay.
2.Another issue for the record/replay scheme is the serialisation of the lpMsg events but these appear to be contiguous in the MFC pump case.
3.The screen display is unimportant for our application and there are a number of ways we could replay that information and synchronize if needed.
Ideally we would like to find a generic solution to this problem, but the important thing at the moment for us is to find a solution that works with DSL tools, but it would be useful to be able to do the same thing for any windows GUI. We would therefore be very grateful for your help with three specific issues.
1.Overriding the various Windows pumps (DSL being our main interest).
2.Serialising the trapped events to file
3.Doing 1) and 2) without causing AVG and other virus checkers complaining. Our earlier executables that used the above technique alert the checker to the fact that we could potentially intercept events such as the entry of passwords and other secure information.
Thank you in anticipation of any help you can give us.
Cheers
Alex