TTimer

[xexxex]

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

[Vad33]

Сообщение от xexxex

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

Да, нужно выключать.

[Stilet]

Да, нужно выключать.

Ну не то чтобы обязательно нужно, но да - это, скажем так, может предотвратить некоторые неожиданности.
А вообще чтоб окончательно избежать такой проблемы лучше использовать Thread а не таймер.

[Slym]

Ничего выключать не надо!!!
Таймер повторно не сработает.
Объясняю:
Таймер - событие и выполняется в потоке выборки сообщений. Пока поток занят выполнением таймерной процедуры, пока принудительно не вызываются ProcessMessages - процедура таймера параллельно предыдущей не запустится, поток то один. Да события/месаджи могут нападать в очередь, но они встанут в очередь и будут ждать пока поток не вернется к разгребанию очереди. Да процедура таймера может сработать раньше чем указано в интервале, а может и позже т.к. таймер имеет низкий событийный приоритет

[Vad33]

Сообщение от Slym

Ничего выключать не надо!!!...

Ну то есть вешаем на срабатывание таймера например
такую процедурку:

procedure TForm1.Timer1Timer(Sender: TObject);
begin
 Application.MessageBox('АХТУНГ','!!!!',MB_OK+MB_ICONERROR);
end;

и радуемся результату в быстром нажимании кнопки?
Не стоит изначально подкладывать себе мины.

[IliaIT]

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

[Serge_Bliznykov]

Slym, Вы заблуждаетесь.
При чём здесь очередь сообщений Windows и процедура в Delphi ?!
Неужели трудно написать простейший код и ПРОВЕРИТЬ то, что Вы утверждаете?!

я сделал это за Вас.
Экспериментируйте:
EXE-шник: Project1EXE.rar
Исходники: Project1Src.rar



А по сути вопроса.
Я лично в подобных случаях, когда возможно срабатывание следующего тика таймера до выхода из текущего, просто использую булевую переменную.
вначале переменная isInTimer := false
Зашли в процедуру таймера, проверили переменную, если она True - сразу вышли.
иначе поставили isInTimer := true
выполнили нужные действия.
при выходе из таймера сделали isInTimer := false

всё. повторные срабатывания нас больше не беспокоят.

[Аватар]

таймер не будет ждать получения ответа от кнопки

Чего не будет? Конкретный тик будет, с каких пор MessageBox асинхронной стало? Другое дело, что такую лободу не чего в таймер сувать, еще бы форматирование диска туда, ага

[Slym]

Сообщение от Serge_Bliznykov

Slym, Вы заблуждаетесь.
При чём здесь очередь сообщений Windows и процедура в Delphi ?!
Неужели трудно написать простейший код и ПРОВЕРИТЬ то, что Вы утверждаете?!

1. А при том! Неужели трудно посмотреть генофонд
таймер это сообщение WM_TIMER

procedure TTimer.WndProc(var Msg: TMessage);
begin
  with Msg do
    if Msg = WM_TIMER then
      try
        Timer;
      except
        Application.HandleException(Self);
      end
    else
      Result := DefWindowProc(FWindowHandle, Msg, wParam, lParam);
end;

2. В вашем коде рекурсия! собработчик таймера запускает обработчик таймера посредством ProcessMessages
3. Я четко указал что параллельно (а в нашем контексте одновременно) таймер не запустится, без вызова ProcessMessages или процедур вызывающих ее аналоги к коим относится MessageBox
т.е. MessageBox можно представить в виде

procedure MessageBoxProc;
begin
  while True do Application.ProcessMessages;
end;

4. и кстати что ваш пример доказывает? то что не рекомендуется ProcessMessages в таймере вызывать или MessageBox?
5. Мой пример.
если таймер <1500мс то срабатывать об будет сразу, но не параллельно, как только закончится предыдущий, т.к. событие уже в очереди

[Serge_Bliznykov]

В вашем коде рекурсия! собработчик таймера запускает обработчик таймера посредством ProcessMessages

почитайте, что такое рекурсия. Тут есть вызов процедурой самой себя?!

С тем, что я разрешаю оконному обработчику разобрать накопившуюся очередь сообщений, в том числе, среди прочих событий разрешаю вызвать процедуру таймера, - с этим я согласен. Да, это так.

и кстати что ваш пример доказывает? то что не рекомендуется ProcessMessages в таймере вызывать

ProcessMessages нужно вызывать в ЛЮБОМ долгом цикле, иначе форма у вас не будет отвечать операционке. Поэтому, если у Вас есть длительная обработка в цикле (не важно, на таймере или нет), то нужно использовать ProcessMessages, обрабатывать очередь сообщений. Иначе ничего на форме работать не будет, пока цикл выполняется.

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

можно было не выкладывать исходник. достаточно было сказать, что Вы в цикле заменили Application.ProcessMessages() на Sleep(10):

  CountTicks := GetTickCount();
  repeat
    // Application.ProcessMessages()
    sleep(10);
  until GetTickCount()>= (CountTicks+1500);

ну и ваш пример убедительно показывает, что так делать НЕЛЬЗЯ.

поставьте время работы процедуры побольше, просто для наглядности, ну, например,

  CountTicks := GetTickCount();
  repeat
    // Application.ProcessMessages()
    sleep(10);
  until GetTickCount()>= (CountTicks+15000);  {15 секунд}

дождитесь, когда таймер сработает:
" таймер сработал в ...."
а теперь попробуйте изменить время, или нажать на кнопку "Stop timer"
или хотя бы, банально, форму по экрану подвигать.
Не получается?! Вот именно!
Это убедительно доказывает, что так, как Вы предлагаете (не использовать ProcessMessages) программировать нельзя!

впрочем. Вы понимаете, о чём я пишу. Я понимаю, о чём Вы пишете.
Думаю, что вопрос исчерапан, sapienti sat.