Overlap Message on WM_TIMER
-
In the case we setting WM__TIMER to the small value for example 20 msec that mean the thread will work on OnTimer function every 20 msec. Assume that, during the thread work on the first period time message in OnTimer function but still not finish, then the second period time message overlap happen so that this message should wait for the first message finish before it continue. Again assume that, the first message not finish and the second message wait for first message, then the third period time message happen. How windows manage this situation. Thanks.
-
In the case we setting WM__TIMER to the small value for example 20 msec that mean the thread will work on OnTimer function every 20 msec. Assume that, during the thread work on the first period time message in OnTimer function but still not finish, then the second period time message overlap happen so that this message should wait for the first message finish before it continue. Again assume that, the first message not finish and the second message wait for first message, then the third period time message happen. How windows manage this situation. Thanks.
WM_TIMER is only posted once. That means that if there is already a
WM_TIMERin the message queue it is not posted again. So at any time there is only oneWM_TIMERin the message queue.«_Superman_» I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) -
WM_TIMER is only posted once. That means that if there is already a
WM_TIMERin the message queue it is not posted again. So at any time there is only oneWM_TIMERin the message queue.«_Superman_» I love work. It gives me something to do between weekends.
Microsoft MVP (Visual C++) -
What about another message, for example WM_MOUSTMOVE if we have a lot of code within OnMouseMove function the first message not finish but another one come in. How windows manage this situation or just ignore it?
There are certain rules involved: 1. Main window procedure can process only one message at the time. 2. WM_TIMER message is posted to a thread’s queue. 3. Messages posted to the queue are retrieved and removed in a main message loop by GetMessage. There is always one global message loop per process. Local message loops can be created but that is not a case here and it does not change this set of rules. 4. Retrieved messages are delivered to a window procedure by DispatchMessage call. 5. When message is processed, system posted messages are not delivered to a message queue, since the thread is blocked. Let’s assume you register timer calling SetTimer. After time elapses, system posts the WM_TIMER message to a queue. Message is then removed and window procedure or callback is called. If timer message is processed for a time much longer that time interval used to register timer, thread id blocked and no messages are added to a queue. If processing time is very long, it will render application unresponsive. After processing is done, queue receives all new messages that are posted by the system. WM_MOUSEMOVE message as other mouse messages are also posted to the queue, hence if thread is blocked by long processing of any message window will loose WM_MOUSEMOVE, resuming receiving after processing is done. Timer is not precise. It has low priority and GetMessage can retrieve other messages first before WM_TIMER is retrieved; it is really at the bottom of the food chain. There is also a set of messages that are delivered by SendMessage directly to a window procedure without being posted. Considering this and low priority of the WM_TIMER it should not be used when timing is crucial. If that is a case, use another thread to handle such a case.
JohnCz MS C++ MVP
-
In the case we setting WM__TIMER to the small value for example 20 msec that mean the thread will work on OnTimer function every 20 msec. Assume that, during the thread work on the first period time message in OnTimer function but still not finish, then the second period time message overlap happen so that this message should wait for the first message finish before it continue. Again assume that, the first message not finish and the second message wait for first message, then the third period time message happen. How windows manage this situation. Thanks.
This is a misuse of WM_TIMER, because it is to often so it will lower performance with its overhead. :(( If you need such high frequencies of calling write a seperate thread which handles such stuff.:thumbsup:
Press F1 for help or google it. Greetings from Germany
-
There are certain rules involved: 1. Main window procedure can process only one message at the time. 2. WM_TIMER message is posted to a thread’s queue. 3. Messages posted to the queue are retrieved and removed in a main message loop by GetMessage. There is always one global message loop per process. Local message loops can be created but that is not a case here and it does not change this set of rules. 4. Retrieved messages are delivered to a window procedure by DispatchMessage call. 5. When message is processed, system posted messages are not delivered to a message queue, since the thread is blocked. Let’s assume you register timer calling SetTimer. After time elapses, system posts the WM_TIMER message to a queue. Message is then removed and window procedure or callback is called. If timer message is processed for a time much longer that time interval used to register timer, thread id blocked and no messages are added to a queue. If processing time is very long, it will render application unresponsive. After processing is done, queue receives all new messages that are posted by the system. WM_MOUSEMOVE message as other mouse messages are also posted to the queue, hence if thread is blocked by long processing of any message window will loose WM_MOUSEMOVE, resuming receiving after processing is done. Timer is not precise. It has low priority and GetMessage can retrieve other messages first before WM_TIMER is retrieved; it is really at the bottom of the food chain. There is also a set of messages that are delivered by SendMessage directly to a window procedure without being posted. Considering this and low priority of the WM_TIMER it should not be used when timing is crucial. If that is a case, use another thread to handle such a case.
JohnCz MS C++ MVP
-
This is a misuse of WM_TIMER, because it is to often so it will lower performance with its overhead. :(( If you need such high frequencies of calling write a seperate thread which handles such stuff.:thumbsup:
Press F1 for help or google it. Greetings from Germany
Well, I do not think this is a WM_TIMER misuse issue. Timer is not posted as high priority message and is retrieved as the last after all others and only during a system idle, that is why is not guaranteed that it will be delivered in intervals it was registered with. The issue here is the fact that timer can be used to handle some long processing and that is what can cause problems.
JohnCz MS C++ MVP
-
Well, I do not think this is a WM_TIMER misuse issue. Timer is not posted as high priority message and is retrieved as the last after all others and only during a system idle, that is why is not guaranteed that it will be delivered in intervals it was registered with. The issue here is the fact that timer can be used to handle some long processing and that is what can cause problems.
JohnCz MS C++ MVP
-
Is it posible to change the priority message in the process? What's function can support this issue ?
No, it is not possible, that is the way OS works. Why is it so important to you? AS I havew already indicated, if you have to do some long processing you would be much better off, moving processing to a dedicated thread, freeing main thread to do GUI updates and process all other messages without freezing.
JohnCz MS C++ MVP
-
Well, I do not think this is a WM_TIMER misuse issue. Timer is not posted as high priority message and is retrieved as the last after all others and only during a system idle, that is why is not guaranteed that it will be delivered in intervals it was registered with. The issue here is the fact that timer can be used to handle some long processing and that is what can cause problems.
JohnCz MS C++ MVP
So the message queue got filled with unworked WM_TIMER messages. What is that positive? If someone needs to handle some stuff he is waiting and nothing is happening. :(( That is not a good style to write a program X| To be honest I would call it a "mistake by design"
Press F1 for help or google it. Greetings from Germany