在windows平台下，一般使用settimer函式建立乙個計時器，killtimer函式用於銷毀乙個計時器。計時器屬於系統資源，使用完應及時銷毀。settimer基於windows的訊息（message），有可能被阻塞。使用wm_timer訊息觸發定時器並不精確。有兩個原因：
原因一：
windows計時器是硬體和rom bios架構下之計時器一種相對簡單的擴充。回到windows以前的ms-dos程式寫作環境下，應用程式能夠通過攔截者稱為timer tick的bios中斷來實現時鐘或計時器。一些為ms-dos編寫的程式自己攔截這個硬體中斷以實現時鐘和計時器。這些中斷每54.915毫秒產生一次，或者大約每秒18.2次。這是原始的ibm pc的微處理器頻率值4.772720 mhz被218所除而得出的結果。在windows 98中，計時器與其下的pc計時器一樣具有55毫秒的解析度。在microsoft windows nt中，計時器的解析度為10毫秒。windows應用程式不能以高於這些解析度的頻率（在windows 98下，每秒18.2次，最大精度達到55ms；在windows nt下，每秒大約100次，最大精度達到10ms）接收wm_timer訊息。在settimer中指定的時間間隔總是截尾後tick數的整數倍。可見，計時器並不能嚴格按照指定的時間間隔傳送wm_timer訊息，它總要相差那麼幾毫秒。即使忽略這幾個毫秒的差別，計時器仍然不精確。
原因二：
wm_timer訊息放在正常的訊息佇列之中，和其他訊息排列在一起，因此，如果在settimer中指定間隔為1000毫秒，那麼不能保證程式每1000毫秒或者989毫秒就會收到乙個wm_timer訊息。如果其他程式的執行事件超過一秒，在此期間內，您的程式將收不到任何wm_timer訊息。事實上， windows對wm_timer訊息的處理非常類似於對wm_paint訊息的處理，這兩個訊息都是低優先順序的，程式只有在訊息佇列中沒有其他訊息時才接收它們。
wm_timer還在另一方面和wm_paint相似：windows不能持續向訊息佇列中放入多個wm_timer訊息，而是將多餘的wm_timer訊息組合成乙個訊息。因此，應用程式不會一次收到多個這樣的訊息，儘管可能在短時間內得到兩個wm_timer訊息。應用程式不能確定這種處理方式所導致的wm_timer訊息「遺漏」的數目。
可見，wm_timer訊息並不能及時被應用程式所處理，wm_timer在訊息佇列中的延誤可能就不能用毫秒來計算了。
由以上兩點，你不能通過在處理wm_timer時一秒一秒計數的方法來計時。如果要實現乙個時鐘程式，可以使用系統的時間函式如getlocaltime ，而在時鐘程式中，計時器的作用是定時呼叫getlocaltime獲得新的時間並重新整理時鐘畫面，當然這個重新整理的間隔要等於或小於1秒。
Linux下定時器使用
linux下的定時器有兩種，以下分別介紹 1 alarm 如果不要求很精確的話，用 alarm 和 signal 就夠了 unsigned int alarm unsigned int seconds 專門為sigalrm訊號而設，在指定的時間seconds秒後，將向程序本身傳送sigalrm訊號，...
Linux下定時器使用
linux下的定時器有兩種，以下分別介紹 1 alarm 如果不要求很精確的話，用 alarm 和 signal 就夠了 unsigned int alarm unsigned int seconds 專門為sigalrm訊號而設，在指定的時間seconds秒後，將向程序本身傳送sigalrm訊號，...
定時器使用
dword winapi checksendinfovector lpvoid lpparameter return 0 void callback dotimer hwnd hwnd,uint umsg,uint ptr idevent,dword dwtime timerproc的引數hwnd是...