How to use Timer in win32 dll?
-
Hi all, I have developed one win32 dll in VC++ for windows mobile. I need to do some work after each 1 hour, So I want to use Timer in this dll. Can any one please let me know that how can i use Timer in dll? Regards, Rahul Vaishnav
-
Hi all, I have developed one win32 dll in VC++ for windows mobile. I need to do some work after each 1 hour, So I want to use Timer in this dll. Can any one please let me know that how can i use Timer in dll? Regards, Rahul Vaishnav
Check if you can use SetTimer with the timer proc. You can also take a look at the API CeRunAppAtTime() if it helps. http://msdn.microsoft.com/en-us/library/aa931253.aspx[^]
modified on Monday, March 8, 2010 2:07 AM
-
Hi all, I have developed one win32 dll in VC++ for windows mobile. I need to do some work after each 1 hour, So I want to use Timer in this dll. Can any one please let me know that how can i use Timer in dll? Regards, Rahul Vaishnav
-
I do not think the original poster wants to schedule his program to start at a certain time. I think he wants his (already running) program to do something at a fixed interval. Very typically, programmers achieve this using a "timer" type. Depending on the specific type used, the timer will either put something through the message loop every so often, or (alternatively) run a callback function every so often. I think the point-of-difficulty that originally led to this thread is the fact that a Win32 DLL does not have a message pump of its own. This makes the use of message-based timers at least superficially more difficult. Really, though, this is not a problem. If the application EXE has a message pump, just have it start a message-based timer and call a designated function of the DLL when the timer elapses. You can document this as a requirement for using the DLL (e.g. "method DllCheckServer() must be called periodical to service the WhipperSnapper feature...") You can probably even instantiate and start the timer from a function in the DLL. However, the EXE's message pump code will at least have to include something to service the timer, if only some kind of boilerplate
case:that calls into the DLL in response to a message. If this approach is not good enough for your nine-layer enterprise architecture (or whatever...) then my suggestion is to use some kind of timer based around an external thread (as opposed to the main message thread of your app). In .NET, for example, System.Timers.Timer runs the timer's event handler automatically on a utility thread. It does not matter whether the main thread is pumping messages or even has a message pump. Of course, then the programmer must worry about events happening outside the main thread, but such is life... There are other options as well. The absolute simplest form of timer is to take the code to be timed (i.e. the "tick" or "elapsed" event handler) and put it in a loop with a Sleep() statement. The sleep time plus the time taken to run the timed code yields the timer interval. The sleep time can even be selected at runtime with each iteration of the loop to achieve a very consistent interval. Of course, this does not allow the utilized thread to do anything else at all, and this must be considered in the overall design, e.g. this is not feasible in the main thread of a GUI app.