settimer(1,10,null)
然后在ontimer中有一个全局变量count来记录ontimer触发次数
然后记录运行时间为time=(count*10)/1000;
为什么这个得到的已经运行的时间偏慢啊
就是现实的一秒时间变得有点长啊

解决方案 »

  1.   

    SetTimer这种定时是由系统维护,消息机制出发的定时,所以有延迟不准确。你可以试试多媒体定时器
      

  2.   

    SetTImer的精度是不高的,一般的15ms左右, 而且WM_TIMER优先级最低,只要消息缓冲区非空,他就不会被投递可以考虑使用多媒体定时器  参看我的博客 高精度多媒体时钟应用类 .
      

  3.   

    如LS所说,WM_TIMER优先级太低,做准确定时很不靠谱.
      

  4.   

    如果一个任务长时间占CPU,那么你的定时器就不会被触发,所以不准是正常的.按楼上说的用多媒体定时器:开一个线程,在线程里计算多媒体时间差值 
      

  5.   

    计时用 DWORD WINAPI GetTickCount(void); 函数。
    DWORD tc = GetTickCount();
    //...
    tc = GetTickCount() - tc;
    这个计时无论在哪儿用都是比较准的。
      

  6.   

    正常的,SetTimer只是定时产生WM_TIMER消息到消息队列末尾而已,而且相同的还会合并,就是如果你5秒钟都没来得及处理WM_TIMER消息的话,最后只能处理一个。想知道运行时间很简单,用GetProcessTimes就能得到进程的启动时间,和现在时间一减就是了,这个是最精确的。GetTickCount虽然也能用于计时,是操作系统启动后的毫秒数,但由于内部计数是32位的,所以31天多后就会重新计数,不适合用于长时间计时。代替GetTickCount可以用GetSystemTime获取系统时间,然后转成FILETIME就能直接相加减。
      

  7.   

    照理说,Timer如果及时处理的话,照你那样用也不会出现什么误差,但关键问题就是,你的周期设得太短了,才10ms,Windows系统线程切换的最小时间片是20ms,你这样注定得不到及时处理,设成1s周期,只要CPU负载不是太重,按照你原始的处理也应该没什么大问题,虽然肯定不精确
      

  8.   

    Timer的精度不够,GetTickCount  , timeGetTime , QueryPerformanceFrequency 等都行,精度比较高