General Information About Windows WM_TIMER MessagesLast reviewed: July 22, 1997Article ID: Q44740 |
3.00 3.10
WINDOWS
kbprg
The information in this article applies to:
SUMMARYTimers in the Windows environment are not synchronous; that is, when a timer "goes off," Windows does not stop processing and send a WM_TIMER message or call the timer event procedure. Instead, Windows sets some bits internally, to ensure that the task that "owns" the timer will run (as soon as the current task does something to yield control). When this task does eventually run and eventually calls GetMessage() or PeekMessage(), and there are no other messages available for this task, Windows will scan the timer list to see if any timers for this task have "gone off." If they have, Windows returns a WM_TIMER message or calls the timer event procedure. The following are two important facts that must be considered:
MORE INFORMATIONThe following is an example of the incorrect use of timers: An application sets a keyboard hook. Inside the keyboard hook, a timer is set. It is important to realize that the keyboard hook is called from within GetMessage() or PeekMessage() whenever a task is pulling keys out of the system queue (the place where keyboard and mouse events go at interrupt level). The task that is active at the time the keyboard hook is called is completely random. Basically, it is the task that owns the windows with the focus. Because a timer is owned by the active task at the time it is created, and any task may be the active task when the keyboard hook is called, the timer created in this manner will be owned by some random task. This, combined with the following facts, results in inconsistent, random behavior for this timer.
|
Additional reference words: 3.00 3.10
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |