Timers tutorial

Introduction
Standard Win32 timers
Multimedia timers
Waitable timers
Queue timers
Make your own timer
Conclusion

Introduction

The goal of this article is to show the practical use of different kinds of timers. First, we will see how to use the "standard" Win32 timers, than we will switch to multimedia timers, mention waitable timers, queue timers and finally "roll our own" timer class. I will try to make some general comparison between these solutions. So called high-resolution timer based on functions QueryPerformanceFrequency and QueryPerformanceCounter will not be taken into account, because this timer can be used only to measure time intervals, and not to "fire events" in regular time intervals. In the first version of this article, I decided to skip waitable timers and queue timers, but after the critics from the readers, I am including them now.

According to MSDN, A timer is an internal routine that repeatedly measures a specified interval, in milliseconds. It means that if we create a timer and specify a time interval of uElapse milliseconds, it will do "something" every uElapse milliseconds, until we destroy it. It is up to us to specify what is "something".

Timers are a powerful feature offered to programmers. However, they often use much of the CPU time, and sometimes it is better to avoid them. Some programmers (especially Visual Basic programmers) tend to use timers for different kinds of polling (e.g. check every 200 milliseconds if the user entered some value into the edit box), which is almost never a good idea. Good candidates for using timers are applications which do not depend that much on users' actions, but rather on time flow.

Standard Win32 Timers

When the term timer is used, it is almost always referred to this kind of timers. I use the term Win32 timer in this article, simply to make distinction between them and other timers. In some texts, these timers are called user timers because they are not kernel objects, unlike waitable and queue timers.

How does this kind of timers work? First, we create a timer, specify its elapse time, and (optionally) attach it to a window. After the timer is created, it sends WM_TIMER messages to the window message queue, or if no window was specified, to the application queue. We can process this message to call the code that we want to be executed in regular time intervals. The timer will send WM_TIMER messages until it is destroyed.

To create a timer, we will use a Win32 function:

UINT_PTR SetTimer(HWND hWnd, UINT_PTR nIDEvent, UINT uElapse, TIMERPROC lpTimerFunc);

or its MFC equivalent:

UINT CWnd::SetTimer(UINT nIDEvent, UINT nElapse, <SPAN class=cpp-keyword>void (CALLBACK EXPORT* lpfnTimer)(HWND, UINT, UINT, DWORD));

Arguments

hWnd	the handle of the window to which the timer is associated; may be NULL, in which case nIDEvent is ignored, and the return value serves as the timer identifier.
nIDEvent	a nonzero timer identifier.
uElapse	timer's time-out interval in milliseconds.
lpTimerFunc	an application-defined callback function that processes WM_TIMER messages. May be NULL (more often than not, it is).

Return value

The timer identifier. If hWnd is non-NULL, than it is equal to nIDEvent. In case of error it is zero.

Now, at some point we may want to stop this "ticking". We can do this by destroying the timer:

BOOL KillTimer(HWND hWnd, UINT_PTR uIDEvent);

or its MFC equivalent:

BOOL CWnd::KillTimer(int nIDEvent);

Arguments:

hWnd - the same value as in the call to SetTimer.
uIDEvent - the timer identifier.

Return value:

If the function succeeds, TRUE; if it fails, FALSE

A typical use of Win32 timers from a CWnd - derived class, looks like this:

void CTimersDlg::OnButtonBegin() 
{
	.
	.
	.
    // create the timer

    SetTimer (m_nTimerID, uElapse, NULL);
}


void CTimersDlg::OnButtonStop() 
{
    // destroy the timer

    KillTimer(m_nTimerID);    	
}

void CTimersDlg::OnTimer(UINT nIDEvent)  // called every uElapse milliseconds

{
	// do something

	.
	.
	.
	CDialog::OnTimer(nIDEvent);

}

So far, so good. Why would we ever want to work with any other kind of timers? Well, it depends on the desired accuracy of the timer. If we want to check our Inbox for new mail every half an hour, Win32 timers are all we want. But for more accurate time measurement (elapsed time less than 1 sec), these timers are hardly the solution. The main reason is that timer posts WM_TIMER messages to a message queue, and we can never be sure when this message will be processed. Now, you might think (as I used to) that setting lpTimerFunc may be a solution to this problem, but that is not true. If you specify lpTimerFunc, the default window procedure calls it when it processes WM_TIMER, not before. So, we will still wait for WM_TIMER to be processed.

Multimedia Timers

The multimedia timer is quite a different creature. It does not post any messages to message queues, but instead calls the specified callback function directly (or, alternatively, it can set or pulse the specific event, but that option will not be covered in this article). Therefore, it is more accurate than the standard Win32 timer, but also more dangerous. Here, we do not have a message queue to protect us if we specify short elapse time.

To use multimedia timers in your projects, you should include Mmsystem.h, and to link it with Winmm.lib

The first step when using multimedia timers, is setting the timer resolution. What is timer resolution? It determines the accuracy of the timer. For instance, if elapse time is 1000, and resolution is 50, multimedia timer will "tick" every 950 - 1050 milliseconds.

That sounds great. Why don't we just set the timer resolution to zero, and have an absolutely accurate timer? That's because different systems support different minimum values for the multimedia timer resolution. We can obtain this minimum value by calling:

MMRESULT timeGetDevCaps(LPTIMECAPS ptc, UINT cbtc);

Arguments:

ptc - pointer to a TIMECAPS structure. It is filled with information about the resolution of the timer device
cbtc - size of TIMECAPS (<SPAN class=cpp-keyword>sizeof (TIMECAPS)).

Return value:

TIMERR_NOERROR if successful or TIMERR_STRUCT if it fails.

TIMECAPS is pretty simple:

typedef struct { 
    UINT wPeriodMin; 
    UINT wPeriodMax; 
	} TIMECAPS;

wPeriodMin - Minimum supported resolution.
wPeriodMax - Maximum supported resolution.

We need to pick our minimum resolution to be in this range. Now, when we have it, let's set the resolution. We will do it by calling the function:

MMRESULT timeBeginPeriod(UINT uPeriod);

Arguments:

uPeriod - Minimum timer resolution.

Return value:

TIMERR_NOERROR if successful or TIMERR_NOCANDO if the resolution specified in uPeriod is out of range.

Now, that we set the resolution, let's create the timer. The multimedia timer equivalent of SetTimer, looks like this:

MMRESULT timeSetEvent(UINT uDelay, UINT uResolution, LPTIMECALLBACK lpTimeProc, DWORD dwUser, UINT fuEvent);

Arguments:

uDelay - Event delay, in milliseconds. Pretty much the same as uElapse in SetTimer.
uResolution - Resolution of the timer event, in milliseconds.
lpTimeProc - Pointer to the callback function that we want to be called periodically.
dwUser - User data passed to the callback function.
fuEvent - Timer event type. May be either TIME_ONESHOT, in which case the callback function is called only once, or TIME_PERIODIC for periodic calling.

Return value:

An identifier for the timer event if successful or NULL if it fails.

Let's take a look at the callback function. It is declared like this:

void CALLBACK TimeProc(UINT uID, UINT uMsg, DWORD dwUser, DWORD dw1, DWORD dw2);

Arguments:

uID - Timer ID, returned by timeSetEvent
uMsg - Reserved.
lpTimeProc - Pointer to the callback function that we want to be called periodically.
dwUser - User data passed to the callback function.
dw1, dw2 - Reserved.

Eventually, we will need to destroy the timer. We can accomplish this by a call to the function:

MMRESULT timeKillEvent(UINT uTimerID);

Argument:

uTimerID - Timer ID.

Return value:

TIMERR_NOERROR if successful or MMSYSERR_INVALPARAM if the specified timer event does not exist.

Remember setting the timer resolution? Well, after we are finished with the timer, we should "reset" the timer resolution with a call to:

MMRESULT timeEndPeriod(UINT uPeriod);

Argument:

uPeriod - The same as in timeBeginPeriod.

Return value:

TIMERR_NOERROR if successful or TIMERR_NOCANDO if fails.

The multimedia timer version of the example from the previous chapter:

void CTimersDlg::OnButtonBegin() 
{
	.
	.
	.
    // Set resolution to the minimum supported by the system

    TIMECAPS tc;
    timeGetDevCaps(&tc, sizeof(TIMECAPS));
    DWORD resolution = min(max(tc.wPeriodMin, 0), tc.wPeriodMax);
    timeBeginPeriod(resolution);     

    // create the timer

    m_idEvent = timeSetEvent(
        m_elTime,            
        resolution,         
        TimerFunction,      
        (DWORD)this,                  
        TIME_PERIODIC);                
}


void CTimersDlg::OnButtonStop() 
{
    // destroy the timer

    timeKillEvent(m_idEvent);
    
    // reset the timer

    timeEndPeriod (m_elTime);

}

void CTimersDlg::MMTimerHandler(UINT nIDEvent) // called every elTime milliseconds

{
// do what you want to do, but quickly

	.
	.
	.
}

void CALLBACK TimerFunction(UINT wTimerID, UINT msg, 
    DWORD dwUser, DWORD dw1, DWORD dw2) 
    {
    // This is used only to call MMTimerHandler

    // Typically, this function is static member of CTimersDlg

    CTimersDlg* obj = (CTimersDlg*) dwUser;
    obj->MMTimerHandler(wTimerID);
    } 

The example shown above is written in a way to resemble the handling of standard Win32 timers. In practice, however, I wrap the functionality of multimedia timers in a separate class, and I recommend you to do the same.

These multimedia timers are just perfect, aren't they? Well, almost. If the resolution is low, or the callback function is lengthy, the system overhead may be very high, and that's why we need to be very careful with them.

Waitable timers

Waitable timers were introduced with Windows 98 and Windows NT 4.0 (which means that we need to define _WIN32_WINNT >= 0x0400, or _WIN32_WINDOWS > 0x0400 before we include windows.h, to work with them), and their main purpose is thread synchronization. These timers are kernel objects which are signaled in the specified time, or in regular time intervals. They can specify the callback function (actually, an asynchronous procedure call, or APC) which gets called when timer gets signaled. This callback function is usually called a completion routine.

In order to enable execution of the completion routine, the thread must be in alertable state (executing SleepEx(), WaitForSingleObjectEx() , WaitForMultipleObjectsEx(), MsgWaitForMultipleObjectsEx() , SignalObjectAndWait() functions). In practice, this means that our main thread will be blocked while we are using waitable timers.

To start working with a waitable timer, we must open an existing timer, or create the new one. Creating can be accomplished with a call to:

HANDLE CreateWaitableTimer(LPSECURITY_ATTRIBUTES lpTimerAttributes, BOOL bManualReset, LPCTSTR lpTimerName);

Arguments:

lpTimerAttributes - pointer to a SECURITY_ATTRIBUTES structure that specifies a security descriptor for the waitable timer object. Can be NULL.
bManualReset - specifies whether the waitable timer is manual-reset or auto-reset.
lpTimerName - the name of the new timer. Can be NULL

Return value:

A handle to the waitable timer object.

Another possibility is to open an existing named waitable timer.

Now, when we have a handle to the waitable timer object, we can do something useful with it. To set it, we will use the function:

BOOL SetWaitableTimer(HANDLE hTimer, const LARGE_INTEGER *pDueTime, LONG lPeriod, PTIMERAPCROUTINE pfnCompletionRoutine, LPVOID lpArgToCompletionRoutine, BOOL fResume);

Arguments:

hTimer - a handle to the timer object.
pDueTime - specifies when the state of the timer is to be set to signaled.
lPeriod - the period of the timer in milliseconds, like uElapse in SetTimer().
pfnCompletionRoutine - the pointer to a completion routine. Can be NULL.
fResume - Specifies whether to restore a system in suspended power conservation mode when the timer state is set to signaled.

Return value:

Nonzero if the function succeeds.

Finally, here is a function that stops the waitable timer:

BOOL CancelWaitableTimer(HANDLE hTimer);

Argument:

hTimer - a handle to the timer object.

Return value:

Nonzero if the function succeeds.

The example will be a little different this time:

void CTimersDlg::OnButtonBegin() 
{
	.
	.
	.
    // create the timer

    timerHandle = CreateWaitableTimer(NULL, FALSE, NULL);
    // set the timer

	LARGE_INTEGER lElapse;
	lElapse.QuadPart = - ((int)elapse * 10000);
	BOOL succ = SetWaitableTimer(timerHandle, &lElapse, elapse, TimerProc,
                this, FALSE);

	for (int i = 0; i < 10; i++)
		SleepEx(INFINITE, TRUE);
	CancelWaitableTimer(timerHandle);
	CloseHandle (timerHandle);
}

void CTimersDlg::WaitTimerHandler() // called every elTime milliseconds

{
// do what you want to do, but quickly

	.
	.
	.
}

void CALLBACK (LPVOID lpArgToCompletionRoutine,
                                DWORD dwTimerLowValue,
                                DWORD dwTimerHighValue)
    {
    // This is used only to call WaitTimerHandler

    // Typically, this function is static member of CTimersDlg

    CTimersDlg* obj = (CTimersDlg*) lpArgToCompletionRoutine;
    obj->WaitTimerHandler();
    } 

As you can see, we don't have OnButtonStop() now. As soon as we set the timer, we must put our calling thread into alertable state, and wait. This means that we can not do anything in the main thread until we finish with the timer. Of course, nothing prevents us to launch a separate thread which won't be blocked. In fact, it would be much better idea to set a timer in a separate worker thread, so that this another thread is blocked, instead of the main thread.

What can we conclude about waitable timers? They do not spend much CPU time and they do not need message queue. The main problem is that the thread which sets the waitable timer must put itself in an alertable state, or the completion routine will never be called. This fact significantly reduces usability of waitable timers.

Queue timers

The last kind of Windows - supported timers that we are going to read about in this article is queue timers. They were introduced with Windows 2000.

Queue timers are lightweight kernel objects that reside in timer queues. Like most timers, they enable us to specify the callback function to be called when the specified due time arrives. In this case, the wait operation is performed by a thread in the thread pool.

Here, for the sake of simplicity, we are not going to create our timer queues. Instead, we will put our queue timers into default timer queue, provided by the OS.

First, we need to create a timer and add it to the default timer queue. For this, we'll make a call to:

BOOL CreateTimerQueueTimer(PHANDLE phNewTimer, HANDLE TimerQueue , WAITORTIMERCALLBACK Callback, PVOID Parameter, DWORD DueTime, DWORD Period, ULONG Flags);

Arguments:

phNewTimer - pointer to a handle; this is an out value
TimerQueue - timer queue handle. For the default timer queue, NULL
Callback - pointer to the callback function
Parameter - value passed to the callback function
DueTime - time (milliseconds), before the timer is set to the signaled state for the first time
Period - timer period (milliseconds). If zero, timer is signaled only once
Flags - one or more of the next values (table taken from MSDN):

WT_EXECUTEINTIMERTHREAD	The callback function is invoked by the timer thread itself. This flag should be used only for short tasks or it could affect other timer operations.
WT_EXECUTEINIOTHREAD	The callback function is queued to an I/O worker thread. This flag should be used if the function should be executed in a thread that waits in an alertable state. The callback function is queued as an APC. Be sure to address reentrancy issues if the function performs an alertable wait operation.
WT_EXECUTEINPERSISTENTTHREAD	The callback function is queued to a thread that never terminates. This flag should be used only for short tasks or it could affect other timer operations. Note that currently no worker thread is persistent, although no worker thread will terminate if there are any pending I/O requests.
WT_EXECUTELONGFUNCTION	Specifies that the callback function can perform a long wait. This flag helps the system to decide if it should create a new thread.
WT_EXECUTEONLYONCE	The timer will be set to the signaled state only once.

Return value:

Nonzero if the function succeeds.

The callback function is really pretty simple:

VOID CALLBACK WaitOrTimerCallback(PVOID lpParameter, BOOLEAN TimerOrWaitFired);

Arguments:

lpParameter - pointer to user-defined data.
TimerOrWaitFired - always TRUE for timer callbacks.

To cancel a queue timer, use the function:

BOOL DeleteTimerQueueTimer(HANDLE TimerQueue, HANDLE Timer, HANDLE CompletionEvent);

Arguments:

TimerQueue - a handle to the (default) timer queue.
Timer - a handle to the timer.
CompletionEvent - a handle to an optional event to be signaled when the function is successful and all callback functions have completed. Can be NULL.

Return value:

Nonzero if the function succeeds.

The example for queue timers is given below:

void CTimersDlg::OnButtonBegin() 
{
	.
	.
	.
    // create the timer

	BOOL success = ::CreateTimerQueueTimer(
		&m_timerHandle,
		NULL,
		TimerProc,
		this,
		0, 
		elTime, 
		WT_EXECUTEINTIMERTHREAD);
}


void CTimersDlg::OnButtonStop() 
{
    // destroy the timer

	DeleteTimerQueueTimer(NULL, m_timerHandle, NULL);  
	CloseHandle (m_timerHandle);
}

void CTimersDlg::QueueTimerHandler() // called every elTime milliseconds

{
// do what you want to do, but quickly

	.
	.
	.
}

void CALLBACK TimerProc(void* lpParametar,                                        
                                    BOOLEAN TimerOrWaitFired)
    {
    // This is used only to call QueueTimerHandler

    // Typically, this function is static member of CTimersDlg

    CTimersDlg* obj = (CTimersDlg*) lpParametar;
    obj->QueueTimerHandler();
    } 

As you can see, queue timers are pretty easy to use. I can also add that they are very accurate, and "resource friendly".

Alas, as I noted at the beginning of this chapter, queue timers are supported only on Windows 2000 and higher. If you do not want to support older Windows versions, they are perfect.

Make your own timer

The question you will ask when you start reading this chapter is: "Why should we develop new timers, when we have four kinds of timers provided by Windows?". Indeed, for almost everything you might want to do in specific time intervals, the timers described above will satisfy your needs. To be quite honest with you, in all the cases that I needed timers, I used standard Win32 timers, except for one project, when I used the multimedia timer to control the work of a pump. However, sometimes you may want to have more control over the timer capabilities, or to make less "OS specific" timers, and here you are.

The general idea, described in this article, is to launch a separate thread which will sleep for the specified time, then call the callback function, than sleep again, and so on until we destroy the timer. Now, I do not claim that this is the best way to make a timer, it is just the simplest that I can think of. Of course, this approach has its drawbacks. The most obvious is that handling threads can often be tricky, especially when it comes to synchronization. It is much harder to debug a multithreaded application, than a single-threaded one. Also, if we want our timer to be more accurate, we will need to mess with scheduling thread priorities.

Having said that, we are going to develop our own timer class. The class declaration might look like this:

typedef void (*ThreadTimerProc)(void* obj, UINT idEvent);

class CThreadTimer  
{  
    void* object;			// pointer to the "parent" object (like CTimersDlg)

    UINT idEvent;			// timer ID

    UINT elapse;			// "Sleep time" in milliseconds

    ThreadTimerProc proc;	// Callback function, supplied by the user


    BOOL isActive;			// Set to FALSE after the call to KillTimer

    CRITICAL_SECTION lock;  // thread synchronization


    static DWORD WINAPI ThreadFunction (LPVOID pParam); // thread entry point

public:
	CThreadTimer();
	virtual ~CThreadTimer();
    
    UINT SetTimer (void* obj, UINT nIDEvent, UINT uElapse, ThreadTimerProc lpTimerProc);
    BOOL KillTimer();
};

Implementation part is shown below:

CThreadTimer::CThreadTimer():object(0),idEvent(0),elapse(0), isActive(FALSE)
    {		
        InitializeCriticalSection(&lock); 
    }

CThreadTimer::~CThreadTimer()
    {
        DeleteCriticalSection(&lock);
    }   

UINT CThreadTimer::SetTimer (void* obj, UINT nIDEvent, UINT uElapse, ThreadTimerProc lpTimerProc)
    {
    object = obj;
    idEvent = nIDEvent;
    elapse = uElapse;
    proc = lpTimerProc;

    EnterCriticalSection(&lock);
    // is it already active?

    if (isActive)
    {
        LeaveCriticalSection(&lock);
        return 0;
    }

    // Start the thread

    DWORD threadId;    
    HANDLE threadHandle = CreateThread (NULL, 0, CThreadTimer::ThreadFunction, this, 0, &threadId);    
    SetThreadPriority(threadHandle,THREAD_PRIORITY_TIME_CRITICAL); // this is optional

    isActive = TRUE;
    LeaveCriticalSection(&lock);
    return nIDEvent;
    }

BOOL CThreadTimer::KillTimer()
    {
    EnterCriticalSection(&lock); 
    isActive = FALSE;
    LeaveCriticalSection(&lock);
    return TRUE;
    }

DWORD WINAPI CThreadTimer::ThreadFunction (LPVOID pParam)
    {
    // Here is the heart of our little timer

    CThreadTimer* obj = (CThreadTimer*) pParam;
    BOOLEAN isActive = TRUE;
    do
        {
        Sleep(obj->elapse);
        obj->proc (obj->object, obj->idEvent);

        EnterCriticalSection(&obj->lock);
        isActive = obj->isActive;
        LeaveCriticalSection(&obj->lock);
        } while (isActive);
    return 0;
    }

Finally, let's see the example from the previous chapters, rewritten to use our thread timer class:

void CTimersDlg::OnButtonBegin() 
{
	.
	.
	.
    // create the timer

    m_timer.SetTimer (this, m_nTimerID, uElapse, TimerFunction);    
}


void CTimersDlg::OnButtonStop() 
{
    // destroy the timer

    m_timer.KillTimer();    	
}

void CTimersDlg::HandleTimer(UINT nIDEvent)  // called every uElapse milliseconds

{
	// do something

	.
	.
	.
}

void TimerFunction(void* obj, UINT idEvent)
{
    CTimersDlg* dlg = (CTimersDlg*) obj;
    dlg->HandleTimer(idEvent);
}

How accurate such timer can be? Pretty accurate, believe it or not. When I tested CThreadTimer, I found that it is somwhere in between the standard Win32 timer and multimedia timer. However, when I changed the process priority to Realtime (using Task manager on my Windows 2000), CThreadTimer seemed to work even better than the multimedia timer. Now, I do not imply that it is wise to change your process priority for the sake of timer accuracy, but sometimes it may be a solution.

Conclusion

Well, what's the moral of the whole story?

When you decide that you need a timer in your application (for some good reason, and not for polling), choosing between the different timer variants should not be that hard. Follow these simple rules:

1. If you want your application to work on every 32 bit Windows platform, and you do not need high precission, use the standard Win32 timer;
2. If you want your application to work on every 32 bit Windows platform, and you need high precission, use the multimedia timer;
3. If you want your application to work on Windows 98/NT4 and higher, you need low system overhead, and can afford to block the calling thread, use the waitable timer;
4. If you want a high-precission, low-overhead, non-blocking timer that will work only on Windows 2000 and higher, use the queue timer;
5. If you want to hack a little, make your timer.

Pretty simple, isn't it? I wish queue timers were introduced with Windows 95, and than we wouldn't need to make such choices.

For professional programming, it is often the best thing to use standard, well-tested solutions. However, hacking with timers can be a real fun, and the possibilities of experimenting seem to be unlimited. Enjoy.

You must Sign In to use this message board.

FAQ  Noise Tolerance Very HighHighMediumLowVery Low  Search Messages    Layout Expand All MessagesThread ViewNo Javascript (slow)No Javascript Preview    Per page 102550

Msgs 1 to 25 of 114 (Total in Forum: 114) (Refresh) FirstPrevNext

Timer Godwin Sam Josh 23:12 22 Oct '08   Hello, Thanks for the article.. But,How do I actually use a win32 timer in my c code? I'm totally new to c...Would it be possible for you to provide me a code snipplet that would work if I paste into my IDE? I tried the stuff you've put thre..but I just can't get it to work Please help me if possible. Thanks so much. Godwin Sign In·View Thread·PermaLink Re: Timer Nemanja Trifunovic 7:34 23 Oct '08   Godwin Sam Josh wrote: But,How do I actually use a win32 timer in my c code? You mean C and not C++? Take a look at MSDN samples[^] Programming Blog utf8-cpp Sign In·View Thread·PermaLink how to accurately get 1ms using multimedia timer sniperong 21:44 5 Aug '08   I have strictly followed the MSDN library and code the timer according to help me achieve my 1ms periodic timer requirement. However the best timing so far I get is 15ms only. This is a snippet code hope this will help to solve the problem. I really hope the community experts could help me in this. I don't know whether is it because I have a hardware limitation I causes the 1ms to fail. As far as I know the RTC on board all intel motherboard can achieve 1ms. #define _WIN32_WINNT 0x500 #define RESOLUTION 1 void main() {       create_watchdogs();             while(1)             {             } } void create_watchdogs(void) {       if(timeGetDevCaps(&tc, sizeof(TIMECAPS)) != TIMERR_NOERROR)       {             printf("Timer device capabilities failed \n");       }             TimerRes = min(max(tc.wPeriodMin, RESOLUTION), tc.wPeriodMax);       if(timeBeginPeriod(TimerRes) != TIMERR_NOERROR)       {             printf("Timer device set resolution failed \n");       }             if((npSeq = timeSetEvent(1,TimerRes,(LPTIMECALLBACK)Resume_1msTask,NULL,TIME_PERIODIC)) == NULL)       {             printf("Set periodic Timer failed \n");       } } void CALLBACK Resume_1msTask(UINT wTimerID, UINT msg, DWORD dwUser, DWORD dw1, DWORD dw2) {       static int i = 0;       static DWORD sum1 = 0;       static DWORD sum2 = 0;             if(i==0)       {             sum1 = timeGetTime();             i = 1;       }       else       {             sum2 = timeGetTime();             sum2 -= sum1;             i = 0;             printf("The time btw task call %d in ms\n",sum2); } Please advice and correct me. Thanx Sign In·View Thread·PermaLink Questions about CreateTimerQueueTimer duddy67 2:55 2 Jul '08   Hi, First, thanks for this article it's very interesting and useful. Now here is my problem: I was expected to use timeSetEvent as a timer for my MIDI sequencer application but I've seen on MSDN site that it's an obsolete function and I should rather use CreateTimerQueueTimer. That's ok for me but I have few questions about it. In my app the timer is used for synchro. An asynchronous callback function is called every 2/3 ms and does it's job. So my questions are: 1 - Since I need just one timer, should I create a queue for the timer with CreateTimerQueue or should I use the default timer queue ? 2 - What flag should I use ? (I would choose WT_EXECUTEINTIMERTHREAD but I'm not sure at all.) WT_EXECUTEDEFAULT WT_EXECUTEINTIMERTHREAD WT_EXECUTEINPERSISTENTTHREAD WT_EXECUTELONGFUNCTION 3 - Timer is used only when sequencer starts playback or recording but what do I do when it stops ? Should I delete timer and create a new one each time sequencer starts playback/recording ? Or is there any way to make the timer hold on without delete it ? Thanks for advance Sign In·View Thread·PermaLink Re: Questions about CreateTimerQueueTimer duddy67 9:46 15 Jul '08   No answer at all ? Anyway, I found out something new: I first tried my code with the timeSetEvent multimedia timer and it seems to work fine. Therefore I tried with the CreateTimerQueueTimer timer and I'm afraid it's no accurate at all. For exemple if I set a tempo at 120 bpm with a resolution of 480 tpb the speed should be the same whatever I set the timer value to 5, 10, 15 or 20ms. But it's not the case. But may be I don't use it properly. So now I'm not sure if I want to use CreateTimerQueueTimer instead timeSetEvent. Is timeSetEvent still available on Windows Vista ? Can someone tells me more about CreateTimerQueueTimer accuracy ? Thanks Sign In·View Thread·PermaLink Re: Questions about CreateTimerQueueTimer Nemanja Trifunovic 10:35 15 Jul '08   duddy67 wrote: the speed should be the same whatever I set the timer value to 5, 10, 15 or 20ms You simply cannot achieve that kind of accuracy with a non-real-time OS, such as Windows; at least not in the user mode. For more information, take a look at the article: Time is the Simplest Thing[^] Programming Blog utf8-cpp Sign In·View Thread·PermaLink Re: Questions about CreateTimerQueueTimer duddy67 11:36 15 Jul '08   Thanks for your fast response You simply cannot achieve that kind of accuracy with a non-real-time OS, such as Windows; at least not in the user mode. Nevertheless there are lot of professional midi sequencers running under Windows with a stable and accurate tempo. Actually the tip to get a stable and accurate tempo is to build a ticks generator (based on a callback function called periodicaly by a timer). It would be too complicate to describe it here but much of midi sequencers are based on it. Anyway, as I said before my prog runs ok with the multimedia timer (timeSetEvent) but encounters issues with CreateTimerQueueTimer. So can I still use timeSetEvent ? (msdn said it's obsolete) Is there a more appropriate way to use CreateTimerQueueTimer ? Thanks Sign In·View Thread·PermaLink Re: Questions about CreateTimerQueueTimer Nemanja Trifunovic 4:45 16 Jul '08   duddy67 wrote: CreateTimerQueueTimer Frankly, the last time I used CreateTimerQueueTimer was when I wrote this article. As for timeSetEvent, it was declared obsolete because it internally calls PulseEven which is bad[^], but whether it is going to affect your application or not, you know better Sorry I can't be of more help - it has been a long time since I researched timers. Programming Blog utf8-cpp Sign In·View Thread·PermaLink Re: Questions about CreateTimerQueueTimer duddy67 11:19 16 Jul '08   what a precious information ! So it doesn't matter in my case because my prog doesn't use the PulseEven flag. I just hope that timeSetEvent will be still available in the futur Windows versions. Thanks for your help. Sign In·View Thread·PermaLink timer to be executed in same thread Angus Comber 9:54 20 Jun '08   Hi I want a really simple timer object which will run in same thread as my main thread (or calling thread). I realise Windows SetTimer will do this but I want for a class where I will not have to create a Windows message loop. I tried the multimedia timer but it runs in its own thread. Any ideas on an approach for this? I can't use any wait functions or this will block my main thread. So I ideally would like to send a message to the operating system which just says - call this function in 2 minutes time. Angus Sign In·View Thread·PermaLink Re: timer to be executed in same thread Nemanja Trifunovic 10:11 20 Jun '08   A waitable timer may be what you are looking for. Just be aware that your thread needs to be in alertable state to recieve the timer notification. Programming Blog utf8-cpp Sign In·View Thread·PermaLink Make your own timer kbat524 2:56 12 Mar '08   Dear all, I use "Make your own timer" to create a timer. After I used member function "setTimer()" to enabl this timer ,this timer seems can't be turn off by calling KillTimer. How do I disable my timer? Thanks very much. Sign In·View Thread·PermaLink Re: Make your own timer Nemanja Trifunovic 4:22 12 Mar '08   Please don't try to use that code directly, at least not in production. It was anly meant to illustrate the concept, not to be used as-is. Why don't you use some of the built-in Windows timers instead? Programming Blog utf8-cpp Sign In·View Thread·PermaLink Timer kumar226 0:41 10 Sep '07   Hi In one of my application.I want to display countdown timer which goes to next question after 30 sec.Please help me to do the same. Thanks in advance thax Sign In·View Thread·PermaLink CreateTimerQueueTimer unresolved external wings2 4:19 31 Jul '07   I get error LNK2001: unresolved external symbol __imp_CreateTimerQueueTimer@28 when attempting to link the Queue timer code provided above. I have installed the latest Platform SDK My Tools->Options->Directories are set to: C:\PROGRAM FILES\MICROSOFT PLATFORM SDK FOR WINDOWS SERVER 2003 R2\INCLUDE C:\PROGRAM FILES\MICROSOFT PLATFORM SDK FOR WINDOWS SERVER 2003 R2\LIB C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE C:\Program Files\Microsoft Visual Studio\VC98\MFC\INCLUDE C:\Program Files\Microsoft Visual Studio\VC98\ATL\INCLUDE In my project settings, link tab, I have Kernel32.lib listed in the object/library modules. What else am I missing? I am using Visual C++ 6.0 on Windows XP pro SP 2 and my application is an MFC dialog based app. As a side note, I thought this was an excellent article. Sign In·View Thread·PermaLink Re: CreateTimerQueueTimer unresolved external wings2 4:22 31 Jul '07   Forgot to mention. I have _WIN32_WINNT=0x500 defined in the preprocessor definitions on the C/C++ tab under the project settings too. Sign In·View Thread·PermaLink Timer code in C++ LLKHANBARI 10:06 15 Jul '07   I am looking for a simple code in C++ to use in my program. Acually my program should run for a specific time (minutes or hours)and after this time finishes the program should output the results. Thanking you Sign In·View Thread·PermaLink 1.00/5 (1 vote) Header file for queue timers LMCer 10:14 31 May '07   What header file do we use to make use of the queue timers capability? IDE: Microsoft Visual Studio 6.0 C++(VC6) Sign In·View Thread·PermaLink linking Winmm.lib scouti179 8:36 8 Apr '07   >>To use multimedia timers in your projects, you should include Mmsystem.h, and to link it with Winmm.lib Hello! I want to use the multimedia timer. I am programming in C++ with Visual Studio 2003. How can I link the Winmm.lib? Thanks in advance for your help! greetings scouti Sign In·View Thread·PermaLink