Important Notice
The pages on this site contain documentation for very old MS-DOS software,
purely for historical purposes.
If you're looking for up-to-date documentation, particularly for programming,
you should not rely on the information found here, as it will be woefully
out of date.
WM_JOURNALNOTIFY (1.2)
◄Up► ◄Next► ◄Previous►
────────────────────────────────────────────────────────────────────────────
#define INCL_WININPUT
Form 1 (Journaling WinQueryQueueStatus)
WM_JOURNALNOTIFY
ulCmd = LONGFROMMP(mp1); /* calling function */
ulQueStatus = LONGFROMMP(mp2); /* queue status */
Form 2 (Journaling WinGetPhysKeyState)
WM_JOURNALNOTIFY
ulCmd = LONGFROMMP(mp1); /* calling function */
sc = SHORT1FROMMP(mp2); /* virtual key */
fsPhysKeyState = SHORT2FROMMP(mp2); /* physical-key state */
A WM_JOURNALNOTIFY message allows the WinQueryQueueStatus and
WinGetPhysKeyState functions to work properly in journaling situations.
Parameter Description
────────────────────────────────────────────────────────────────────────────
ulCmd Low and high word of mp1. Specifies the function that was
called. This value is JRN_QUEUESTATUS for the
WinQueryQueueStatus function and JRN_PHYSKEYSTATE for the
WinGetPhysKeyState function.
ulQueStatus Low and high word of mp2. This parameter is used when the
ulCmd parameter is JRN_QUEUESTATUS. This parameter contains
the queue status returned by the WinQueryQueueStatus
function.
sc Low word of mp2. This parameter is used when the ulCmd
parameter is JRN_PHYSKEYSTATE. This parameter specifies the
virtual-key value in the low byte and contains zero in the
high byte.
fsPhysKeyState High word of mp2. This parameter is used when the ulCmd
parameter is JRN_PHYSKEYSTATE. This parameter specifies the
physical-key state, returned by a call to
WinGetPhysKeyState. The 0x8000 bit is set (less than zero)
if the key is down; it is clear if the key is up. The 0x0001
bit is set if the key has been pressed since the last time
WinGetPhysKeyState was called; it is clear if the key has
not been pressed. This 0x0001 bit is cleared by a call to
WinGetPhysKeyState.
Return Value
An application should return zero if it processes this message.
Comments
Both of these functions depend on scanning a complete message queue, but
journal playback effectively uses a queue that is just one message long.
To fix these journal-related problems, calls to WinQueryQueueStatus and
WinGetPhysKeyState must be recorded along with appropriate state
information. This is done using WM_JOURNALNOTIFY messages. If the functions
have new information to return since the last time they were called, and
there is a journal-record hook installed, the system sends a
WM_JOURNALNOTIFY message, carrying a function indicator and the new state
information. During journal playback, the system interprets the
WM_JOURNALNOTIFY message and changes the appropriate physical-key state
entry or queue status to reflect the state of the system at the time the
message was recorded.
Because the WinQueryQueueStatus and WinGetPhysKeyState functions can be
called by applications other than the one currently processing input, it is
possible that the journal-record hook will be called by two threads
simultaneously. For this reason, it is important that the journal library
use semaphores when accessing global variables.
See Also
WinGetPhysKeyState, WinQueryQueueStatus
♦