Здравствуйте.
У меня наблюдается чрезвычайно странный глюк.
Вот простейший код в Билдере (форма с таймером):



Через какие-то неравные промежутки времени инкрементирование числа останавливается и висит в таком положении какие-то доли секунды, потом опять продолжается. Причем, без скачка.
Я бы мог подумать, что это виснет моя программа, но раз используется системный таймер, то, получается, это он тормозит. Т.е. у меня весь компьютер виснет на какие-то доли секунды вместе с системным таймером (страшная вещь). Но если бы это было так, мои часы (те, что в трее) постепенно начинали бы отставать, но они идут исправно.

Подскажите, пожалуйста, в чем может быть проблема, у меня голова уже не варит.

На какой интервал настроен Timer1? При малых интервалах так вполне может быть

Не важно, на какой. Например на 1000 или 100 мс. А почему на малых вдруг такое может быть?

Event'ы от таймера приходят в виде сообщений через общую очередь сообщений. Если интервал маленький или в цикле обработки сообщений есть какие то процедуры занимающие много времени, то event'ы от таймера будут накапливаться в очереди и потом отрабатываться пачками.

Если хотите чтобы было все ровно, то запустите поток, а в нем пытайтесь отсчитывать время, если на экран не будете выводить, то тормозить не будет, при выводе на экран опять могут начаться такие косяки, т.к. придется использовать Synchronize.

Во первых Timer не рекомендуется использовать на интервале меньше 50.
Во вторых лучше явно приводить к типу указанному в сигнатуре функции. Не стоит уповать на приведение типов Бормана по умолчанию.

В третьих что такого ужасного выводить данные в компонент - типа метки или statictext и забить на канву?

сообщения WM_TIMER не будут накапливаться, т.к. они запихиваются в очередь только при отсутствии в ней других сообщений. В любом случае, это не причина моей проблемы, т.к. возобновление обработки сообщений вызывало бы скачок счетчика, а, как я уже писал, его нет.

И так должно быть все равно, без использования потоков и синхронизации. Ведь нет привязки к количеству вызовов обработчика таймера. Прошедшее время узнается уже в самом обработчике. А как по Вашему, если я сделаю все как Вы сказали, такого не будет? Вряд ли. Мне ведь все равно придется использовать GetTickCount (ну или GetSystemTime/GetLocalTime), а похоже, что причина именно в них.

Абсолютно ни чем не лучше, если ты знаком со всеми ее перегруженными вариантами. В данном случае их вообще нет. Тогда уж не String, а AnsiString. И, самое интересное, кто такой Борман?

Абсолютно ничего ужасного. Я уже перепробовал по всякому. Причина не в этом, причина в ф-ии GetTickCount. Я не использовал лэйблоподобный контрол в примере только потому, чтобы Вам было легче воспроизвести пример.

Борман шутливое название Борланда.
А теперь объясни мне разницу в билдере между String и AnsiString?


Это сообщение отредактировал(а) mrbrooks - 16.5.2008, 09:23

Не совсем:
Т.е. WM_TIMER все же могут накапливаться.
Точно нет? Визуально его можно и не увидеть. Проверь значение, которое будет выведено через пару минут после старта программы (по часам).

Если причина в GetTickCount то не поможет,

События таймеры ваполняются в основном потоке, поэтому таймеру приходится подвинуться, если вы выполняете какие-то действия с интерфейсом, думаю всетаки в этом причина, 
да и к томуже не такая сложная задача сделать это в новом потоке, максимум что можно потерять - это 10 минут времени.


Это сообщение отредактировал(а) Artemon - 16.5.2008, 14:56

Никакой. Просто я так понял, что ты хочешь следовать сигнатуре функции.




А VCL использует DispatchMessage всегда. Правда эту фразу тоже можно понять двояко, что имеется в виду под "другими сообщениями" - любые сообщения, уже содержащиеся в очереди, или сообщения, отличающиеся от WM_TIMER.

Добавлено через 2 минуты и 33 секунды
Провел несколько тестов.
Результаты очень интересные.

Запустил прогу и сверял по механическому секундомеру.
После 5 минут задержка составила ~ 25 секунд.
После 10 минут задержка составила ~ 48 секунд.

Запустил два экземпляра проги (в разное время). Обе проги тормозили абсолютно синхронно. Т.е. счетчик останавливался и снова запускался в обоих прогах одновременно, хотя запущены они были в разное время. Отсюда я опять делаю вывод, что тормозят именно системные часы. Но, повторюсь, часы в трее идут исправно. Стало быть, они используют другие механизмы, отличные от вызовов GetTickCount/GetSystemTime/GetLocalTime.
Все никак не могу проверить на другом компьютере. Кто-нибудь проверял данный код? Ни у кого больше задержки не было?

Я либо скоро стану идиотом, либо поверю в колдовство, либо раскрою страшный баг Windows. Или это будет баг Матрицы. А может это будет парадокс, который повлечет за собой цепную реакцию и разрушение вселенной...

Попробовал без использования VCL, на WinAPI.





Та же самая история...