SetTimer, nIDEvent and timer identification
-
I want to use timers do some actions. I read about
UINT SetTimer(HWND hWnd, UINT nIDEvent, UINT uElapse, TIMERPROC lpTimerFunc );versus theCWnd::SetTimer, UINT nIDEvent, UINT uElapse, TIMERPROC lpTimerFunc );There is a nice document here explaining some facts. However, I still have some questions about who is handling the timers. I want to create and handle the timers inside a CScrollView (by mapping and overwriting the inheritedCWnd::OnTimer(UINT nIDEvent)and not via a TIMERPROC. However, I am not sure which timer creation function to use and what value will be good for the nIDEvent on them. i. How do I guarantee that the CScrollView which created the timer is the one that receives the WM_TIMER message (and subsequently process it). Is it possible that the WM_TIMER expiration message ends up on another queue (I found that this is possible for mouse messages) or only the creating window can get it? ii. Is the nIDEvent identifier a system unique one or a view unique one? How do I get a sufficiently unique nIDEvent value to make sure that I am processing the right timer? iii. Is it possible that my CScrollView will receive time outs (i.e. WM_TIMER messages) by other views or even other threads or applications and under which conditions? If yes what should I do with those timers? iv. Any idea why SetTimer may fail? Is this due to a system limit on running timers or due to a non unique nIDEvent? How can I know? Dimitris -
I want to use timers do some actions. I read about
UINT SetTimer(HWND hWnd, UINT nIDEvent, UINT uElapse, TIMERPROC lpTimerFunc );versus theCWnd::SetTimer, UINT nIDEvent, UINT uElapse, TIMERPROC lpTimerFunc );There is a nice document here explaining some facts. However, I still have some questions about who is handling the timers. I want to create and handle the timers inside a CScrollView (by mapping and overwriting the inheritedCWnd::OnTimer(UINT nIDEvent)and not via a TIMERPROC. However, I am not sure which timer creation function to use and what value will be good for the nIDEvent on them. i. How do I guarantee that the CScrollView which created the timer is the one that receives the WM_TIMER message (and subsequently process it). Is it possible that the WM_TIMER expiration message ends up on another queue (I found that this is possible for mouse messages) or only the creating window can get it? ii. Is the nIDEvent identifier a system unique one or a view unique one? How do I get a sufficiently unique nIDEvent value to make sure that I am processing the right timer? iii. Is it possible that my CScrollView will receive time outs (i.e. WM_TIMER messages) by other views or even other threads or applications and under which conditions? If yes what should I do with those timers? iv. Any idea why SetTimer may fail? Is this due to a system limit on running timers or due to a non unique nIDEvent? How can I know? Dimitrisi. If you do "this->SetTimer(100, 2000, NULL)" inside your CScrollView class it will use the handle for your view. ii. It is unique to your view. How many timers are you planning on using? If just one declare a constant. iii. Yes if some sends the WM_TIMER message to that view. Really shouldn't happen though. iv. How do you know it's failing?
-
i. If you do "this->SetTimer(100, 2000, NULL)" inside your CScrollView class it will use the handle for your view. ii. It is unique to your view. How many timers are you planning on using? If just one declare a constant. iii. Yes if some sends the WM_TIMER message to that view. Really shouldn't happen though. iv. How do you know it's failing?
Thanks a lot. It clarifies a lot of things. Thus, I can be sure that my view and only this will handle the timers. My plans are to use one timer primarely but there are some rare cases that I may have two running similtaneously. However, if their ids are view unique ones I can use constants to guarantee uniquness and I am assuming that noone sends to my view a WM_TIMER message (according to what you said it sounds a reasonable assumption. Note that the thread will have more than one CScroll views of the same or different type). According to my reading SetTimer indicates failure if it returns zero. Thus, I know that it is failed to create a timer. But it seems to me that this is due to system resources limits thus, nothing that I can do about it. Well, was quite helpfull clarifying these points, hope now that they will work like these. Dimitris...
-
Thanks a lot. It clarifies a lot of things. Thus, I can be sure that my view and only this will handle the timers. My plans are to use one timer primarely but there are some rare cases that I may have two running similtaneously. However, if their ids are view unique ones I can use constants to guarantee uniquness and I am assuming that noone sends to my view a WM_TIMER message (according to what you said it sounds a reasonable assumption. Note that the thread will have more than one CScroll views of the same or different type). According to my reading SetTimer indicates failure if it returns zero. Thus, I know that it is failed to create a timer. But it seems to me that this is due to system resources limits thus, nothing that I can do about it. Well, was quite helpfull clarifying these points, hope now that they will work like these. Dimitris...
Hello, do you have:
ON_WM_TIMER()in your Messagemap included?? than you have to call the function like this:// but befor call OnTimer you have first set the timer in some other funktion: int SomeOtherFunc() { nIDEvent = SetTimer(iTimerIdentifier, iIntervalMiliSecond,0); //iTimerIdentifier is stored in nIDEvent for use in OnTimer(UINT nIDEvent), iIntervalMiliSecond is the time to wait between intervals // example nIDEvent = SetTimer(2, 1000,0); } afx_msg void MyAppDlg::OnTimer(UINT nIDEvent) { // do something with this nIDEvent switch(nIDEvent) { case 1: { ... break; } case 2: { // in my example the OnTimer jump here, and i can do something ... ... break; } //etc. default: break; } } ....give peace of code to see what you coding to set and start timer! break; -- modified at 11:13 Wednesday 19th July, 2006