Стандартные средства
Как известно, компонент TTimer основан на User таймерах, предоставляемых Win32API. Это просто VCL-оболочка, удобная для использования "на форме" системных таймеров данного типа. Для их работы требуется окно, поскольку программа получает извещение о срабатывании таймера посредством сообщения WM_TIMER. Без участия VCL для работы с ними необходим обработчик сообщения WM_TIMER и функции API:
CreateTimer SetTimer KillTimer
Да чем же они плохи, эти User таймеры? А вот чем!
- Недостаток 1.
Как известно, сообщения в Win32 обрабатываются в следующем порядке очередности:
- синхронные сообщения (от SendMessage)
- асинхронные сообщения (от PostMessage)
- завершение приложения или WM_QUIT (от PostQuitMessage)
- асинхронный ввод (мышь, клавиатура)
- требование прорисовки или WM_PAINT
- извещения от User таймеров или WM_TIMER
Таким образом, сообщение WM_TIMER имеет наименьший приоритет и принимается только когда в очереди потока нет других сообщений. Это значит, что своевременному получению "тика" от User таймера может помешать как длительная обработка синхронных и асинхронных сообщений, так и реакция на интенсивный ввод пользователя, и даже активная перерисовка окон.
- Недостаток 2.
Кроме того, повторные сообщения WM_TIMER от того же таймера уничтожаются, если в очереди еще есть необработанное такое же. Все это приводит к потере тиков таймера, в результате программа получает меньше вызовов обработчика таймера на заданном интервале, чем рассчитывал программист.
- Недостаток 3.
Нельзя сделать так, чтобы моменты срабатывания были привязаны к системному времени (были синхронны с ним), т.е. чтобы таймер тикал в определенные часы, минуты, секунды. Он обязательно будет "уплывать".
- Недостаток 4.
О срабатывании таймера User уведомляется только один поток (тот, который вызвал SetTimer), поэтому невозможно пробудить по таймеру сразу несколько потоков.
- Недостаток 5.
Дискретность временного интервала оставляет желать лучшего. В Win9x она составляет 55 мс. Но даже в NT интервал квантуется не менее чем по 10 мс.
