In this section:
A simple method is available to enable mouse and keyboard actions within a ClearWin+ application to be recorded and replayed. This facility should be thought of as a debug/test facility as it cannot be made totally reliable if the circumstances of the playback differ from those of the recording. In particular, mouse positions will differ if playback occurs at a different screen resolution (see below). The format of recorded files may also vary between versions of ClearWin+.
Recording is enabled by calling START_CLEARWIN_RECORDER@. This subroutine takes one CHARACTER variable specifying the name of the file to hold the recording. Recorded operations are written to the file immediately (rather than being buffered) to help in situations in which the application aborts. Recording stops when STOP_CLEARWIN_RECORDING@ is called, or when the application terminates. The file is created as a text file, and here are some typical contents:
<LEFT_MOUSE_DOWN,BT008/1,95,24>
<LEFT_MOUSE_UP,BT008/1,95,24>
<LEFT_MOUSE_DOWN,BT005/2,24,13>
<LEFT_MOUSE_UP,BT005/2,24,13>
<LEFT_MOUSE_DOWN,MAIN/1,4,1>
<LEFT_MOUSE_UP,MAIN/1,4,1>
Each event occupies one line of the file and starts with a name for the event. The second field names the control receiving the input. For example, the first two lines refer to button number 8 of the first ClearWin+ window. A name in this form is known as a fully qualified control name. Observe that the first two letters of a control name are derived from the format used to create it. Sometimes a user clicks on the main window rather than a control. In this case the 'control name' field has the form shown in the last two lines above. The last two fields for mouse operations are the co-ordinates of the mouse relative to the control in question.
Note that this scheme at least means that some mouse operations, such as button clicks, are unaffected by changes in screen resolution. The reason why recorded input does not make explicit reference to Windows handles is that different handle numbers will be supplied by Windows each time a program is run.
The control naming scheme is effective whether or not recording has been enabled. The following two routines can be used to convert between control names and the corresponding Windows handles:
INTEGER(7) HANDLE_FROM_CONTROL_NAME@(NAME)
CHARACTER(*) NAMECHARACTER*10 CONTROL_NAME_FROM_HANDLE@(H)
INTEGER(7) H
These routines will generate incorrect results if they are given bad arguments.
The subroutine START_CLEARWIN_PLAYBACK@ can be used to play back a recorded file. This subroutine takes one CHARACTER variable specifying the name of the file that holds the recording. When play back is completed, normal mouse and keyboard input is resumed.
It is vital that the playback does not deviate from the recording in any way. For example, if your application displays an extra window if some file is present, then that file must be either present for both the recording and playback, or absent for both.
The problem of mouse actions being sensitive to the screen resolution and font sizes is ameliorated somewhat by the following:
a) Menus, edit boxes, and text arrays store additional information that stores the data in a resolution-insensitive form. This facility may be extended to cover more controls in future.
b) Mouse co-ordinates are always stored relative to the control in which they occur. This means that, for example, a mouse click at point (40,50) in a graphics area of some fixed resolution will be recorded correctly.