WM_TIMER message never arrives [modified]
-
Hanan888 wrote:
with no time delay
You cannot be sure of that. The timer resulution in WinNT is about 10 ms, it could take as long as that before the first WM_TIMER is fired.
-
Thank You. I don't need any accuracy in the time delay. My typical usage is to set the timer with several seconds delay. My problem is that it never arrives, breakpoint in
case WM_TIMER:never gets hit. -
Thank You. I don't need any accuracy in the time delay. My typical usage is to set the timer with several seconds delay. My problem is that it never arrives, breakpoint in
case WM_TIMER:never gets hit.Hm, you're using PM_REMOVE in PeekMessage, maybe it gets removed from the queue before it hits your message loop?
-
Hm, you're using PM_REMOVE in PeekMessage, maybe it gets removed from the queue before it hits your message loop?
-
Thank You, really I didn't think of checking the return value. but now I checked and it seems alright
result = SetTimer(m_hWnd, SPECIFIC_CONSTANT ,10000, NULL);after this, result = SPECIFIC_CONSTANT .result = SetTimer(m_hWnd, SPECIFIC_CONSTANT ,10000, NULL); You get WM_TIMER after 10 sec. 10000 ms. == 10 sec.
-
Thanks. As far as I know, it is removed from queue. But it gets in the
msgvariable, then processed.MSDN says "PeekMessage does not retrieve messages for windows that belong to other threads.". So, the messages from your queue will not be removed by others. They will be in queue till you Peek or Get messages. And you can not PeekMessage from a window queue, where the window is not created by your thread
-
result = SetTimer(m_hWnd, SPECIFIC_CONSTANT ,10000, NULL); You get WM_TIMER after 10 sec. 10000 ms. == 10 sec.
-
MSDN says "PeekMessage does not retrieve messages for windows that belong to other threads.". So, the messages from your queue will not be removed by others. They will be in queue till you Peek or Get messages. And you can not PeekMessage from a window queue, where the window is not created by your thread
thanks.
ramana.g wrote:
MSDN says "PeekMessage does not retrieve messages for windows that belong to other threads.". So, the messages from your queue will not be removed by others. They will be in queue till you Peek or Get messages. And you can not PeekMessage from a window queue, where the window is not created by your thread
AS far as I know, all my windows and all my application is one thread.
-
Thank you.
Rajkumar R wrote:
This can lead to busy loop, as peekmessage returns without waiting for messages. This may not be the problem. This can use significant processor time.
I was sure that my message peeking loop was pretty standard. I can't see the problem you indicated. Please describe it if you have the time.
Rajkumar R wrote:
Are you creating the windows in the same thread as the message loop?
I dont do any special threading now, working pretty standard so I guess I am creating the windows in the same thread. please note: all other messages (automatic-win32-messages) arrive where I expect them.
Hanan888 wrote:
I was sure that my message peeking loop was pretty standard. I can't see the problem you indicated. Please describe it if you have the time.
"pretty standard" please give the standard committee link for this. typically, in win32 samples, i seen message loop with GetMessage() in winmain like, while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0) { if (bRet == -1) { // handle the error and possibly exit } else { TranslateMessage(&msg); DispatchMessage(&msg); } } PeekMessage is used, if you are doing some lengthy operation and want to examine the message queue in between.
Hanan888 wrote:
Please describe it if you have the time.
just replace your message loop with GetMessage() and compare the processor usage in Task Manager. In my HT machine, i am getting almost 0% using GetMessage(), and using your peekmessage() more than 50%, iam sure in single processor machine it will be more than 90%.
-
Hanan888 wrote:
I was sure that my message peeking loop was pretty standard. I can't see the problem you indicated. Please describe it if you have the time.
"pretty standard" please give the standard committee link for this. typically, in win32 samples, i seen message loop with GetMessage() in winmain like, while( (bRet = GetMessage( &msg, NULL, 0, 0 )) != 0) { if (bRet == -1) { // handle the error and possibly exit } else { TranslateMessage(&msg); DispatchMessage(&msg); } } PeekMessage is used, if you are doing some lengthy operation and want to examine the message queue in between.
Hanan888 wrote:
Please describe it if you have the time.
just replace your message loop with GetMessage() and compare the processor usage in Task Manager. In my HT machine, i am getting almost 0% using GetMessage(), and using your peekmessage() more than 50%, iam sure in single processor machine it will be more than 90%.
Thank you for the info. My way was standard in DirectX samples. if
PeekMessage()returns false (no messages in queue) I do graphic rendering. My recent check showed that if I doPostMessage()(instead ofsetTimer())I get exactly where I wanted. Still, I must use timer to acheive the delay. -
Thank you for the info. My way was standard in DirectX samples. if
PeekMessage()returns false (no messages in queue) I do graphic rendering. My recent check showed that if I doPostMessage()(instead ofsetTimer())I get exactly where I wanted. Still, I must use timer to acheive the delay.Hanan888 wrote:
I do graphic rendering.
That's it you are performing lengthy operation.
Hanan888 wrote:
Still, I must use timer to acheive the delay.
in your rendering loop, you can find the elapsed time since last time message posted and find out the delay. And if you find that delay you actually don't need to post message, you can call the handler for WM_TIMER directly in the rendering loop. but still i am not convinced why SetTimer() is not working.
-
Hanan888 wrote:
I do graphic rendering.
That's it you are performing lengthy operation.
Hanan888 wrote:
Still, I must use timer to acheive the delay.
in your rendering loop, you can find the elapsed time since last time message posted and find out the delay. And if you find that delay you actually don't need to post message, you can call the handler for WM_TIMER directly in the rendering loop. but still i am not convinced why SetTimer() is not working.
Thanks again.
Rajkumar R wrote:
in your rendering loop, you can find the elapsed time since last time message posted and find out the delay. And if you find that delay you actually don't need to post message, you can call the handler for WM_TIMER directly in the rendering loop.
Yes, in rendering I check the time now and calculate the delay or something like that (some other from my team implemented these stuff). But what I need is triggering some GUI and rendering and business-logic events, orchestrating them with time delays. And it all worked before something got funky. All messages (PAINT, LBUTTONDOWN,...) go exactly where I need them.
PostMessage(m_hWnd,WM_TIMER,SPECIFIC_CONST,NULL);get where I expect it to go. onlySetTimer(m_hWnd,SPECIFIC_CONST,1000,NULL)never get to thecase WM_TIMER:Rajkumar R wrote:
but still i am convinced why SetTimer() is not working.
Do you mean you're still not convinced ?
-
In my Win32 application, I register several window classes, each class have a different message procedure. Then, I create several windows. I call
SetTimer(m_hWnd, SPECIFIC_MESSAGE_CONSANT,1000, NULL);As far as I know: This should send a WM_TIMER with wParam = SPECIFIC_MESSAGE_CONSANT, with one second time delay. To the message procedure of the window class that m_hWnd (HWND) was created from. whereSPECIFIC_MESSAGE_CONSANT = 11761In my int APIENTRY _tWinMain() I do:MSG msg; ZeroMemory( &msg, sizeof(msg) ); while( msg.message!=WM_QUIT ) { if( PeekMessage( &msg, NULL, 0U, 0U, PM_REMOVE ) ) { _//my WM_TIMER dont get here_ TranslateMessage( &msg ); DispatchMessage( &msg ); } else { } }WM_TIMER never arrives to the place marked above. I triedPostMessage(m_hWnd,WM_TIMER,SPECIFIC_MESSAGE_CONSANT,NULL)-> got exactly where expected. Still, I must have the time delay.modified on Tuesday, February 26, 2008 6:20 AM
Thank you all for help and invaluable knowledge !!! I sure learned a lot. It turns out, I stuck too much in the
case WM_PAINT:, and that clogged theWM_TIMERmessages. I rendered all my windows onWM_PAINT(DirectX stuff). Now, When I drag my windows some ungraceful visual effects happen, but I guess I'll manage.