TTimer

[Slym]

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

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

Скажи и тут нет рекурсии?

procedure First;
begin
  Second;
end;
procedure Second;
begin
  Third;
end;
procedure Third;
begin
  First;
end;

First();

а в твоем примере если выставить таймер менее 10мс, через 30 сек будет EStackOverflow - обычно получаемую при глубокой рекурсии

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

Это убедительно доказывает, что так, как Вы предлагаете (не использовать ProcessMessages) программировать нельзя!

И не убедительно и не доказывает, и ничего не висит

program Project1;
{$APPTYPE CONSOLE}
uses Windows;
begin
  while True do
    Sleep(10);
end.

[xexxex]

Ну, в общем, всё понятно, лучше "перебздеть, чем недобздеть" - и каждый вход в событие OnTimer либо синхронизировать внешней булевой переменной, либо в самом событии выключать\включать таймер при входе\выходе из события.
Всем спасибо!

[Serge_Bliznykov]

Скажи и тут нет рекурсии?

Вы будете удивлены, но рекурсия - она же разная бывает.
Прямой (или простой) рекурсии - тут, разумеется, нет.

цитирую с википедии:

В программировании рекурсия — вызов функции (процедуры) из неё же самой, непосредственно (простая рекурсия) или через другие функции (сложная или косвенная рекурсия), например, функция A вызывает функцию B, а функция B — функцию A.

соглатитесь, что если мы напишем так:

procedure Third;
begin
  // скрытый код..
end;

то уже вроде как рекурсии и нет.
поэтому, когда Вы вызываете какую-то функцию, например,
Application.Restore
Вы можете знать, есть там обработка очереди сообщений? Это рекурсивный вызов?
Это раз.

Второе. Вы меня не переубедите.
Нормальная программа должна отдавать тики операционной системе. Это и выполняется (в явную) через ProcessMessage.
При чём здесь консольное приложение

program Project1;
{$APPTYPE CONSOLE}
uses Windows;
begin
  while True do
    Sleep(10);
end.

я, честно говоря, не понимаю.
Вы хотите показать, что окно всё равно обрабатывается? Ну так правильно. В консоли можно же запустить программу, которая не имеет оконного обработчика и, соотвественно, не отдаёт тики системе.
А Вы написали много консольных программ, использующих TTimer?
Или это просто так пример, для поддержания разговора?
А не хотите подобный код вставить в обработчик событий формы или на таймер.
Тоже всё будет так же хорошо?

а в твоем примере если выставить таймер менее 10мс, через 30 сек будет EStackOverflow - обычно получаемую при глубокой рекурсии

в каком моём примере?!
В том, где я показываю, что процедуру таймера НЕЛЬЗЯ оставлять без защиты от повторного вызова и там же, где в коде написано:

  IntervalTimer := StrToIntDef(Edit1.Text, 0);
  if IntervalTimer < 500 then begin
     Application.MessageBox('Нельзя вводить интервал меньше 500!', 'Error', MB_OK);
     Exit
  end;
  Timer1.Interval := IntervalTimer;

Slym, скажите, а в чём Вы меня пытаетесь убедить? В том, что TTimer не нужно использовать? Или в том, что внутри TTimer нельзя писать длинные циклы? Или в том, что в длинных циклах нельзя использовать фунции, позволяющие обработать очередь оконных сообщений?



xexxex, правильно, дьявол кроется именно в деталях. Нужно смотреть конкретный код, конкретную процедуру. И, как правильно сказано в теме, не стоит вешать на таймер очень длинные процедуры, или процедуры, которые заведомо не имеют фиксированной длительности, например, ожидание ввода данных пользователем в InputBox...

[Slym]

в вашем примере если таймер будет выполнятся дольше, периода сработки т.е. более 1500мс (а в непредсказуемой многозадачности это влегкую): EStackOverflow - вопрос времени, и пихать такой код в таймер в приложении 24/365 я бы не стал.

А убедить пытаюсь не вас, а топикстартера, чтоб не копипастил ваши примеры

[Serge_Bliznykov]

EStackOverflow - вопрос времени, и пихать такой код в таймер в приложении 24/365 я бы не стал.

А убедить пытаюсь не вас, а топикстартера, чтоб не копипастил ваши примеры

Вы, наверное, не понимаете, о каких примерах идёт речь.
На мой взгляд, процедура, висящая на таймере, если есть малейшее подозрение, что время работы этой процедуры может быть БОЛЬШЕ, чем интервал таймера, может выглядеть следующим образом:

type
  TForm1 = class(TForm)
    Timer1: TTimer;
    Memo1: TMemo;
    Edit1: TEdit;
    Label1: TLabel;
    btSart: TButton;
    Label2: TLabel;
    btStop: TButton;
    procedure Timer1Timer(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure btSartClick(Sender: TObject);
    procedure btStopClick(Sender: TObject);
  private
    isInTimer1 : boolean;
  public
    { Public declarations }
  end;

var
  Form1: TForm1;

implementation

{$R *.DFM}

procedure TForm1.FormCreate(Sender: TObject);
begin
  Memo1.Lines.Clear;
  btStop.Enabled := false;
  isInTimer1 := false;
end;


procedure TForm1.Timer1Timer(Sender: TObject);
var i : integer;
  dt : tdatetime;
  CountTicks : DWORD;
begin

  if isInTimer1 then Exit;
  isInTimer1 := true;

  dt := now;
  Memo1.Lines.Append(' таймер сработал в '+TimeToStr(dt));

  CountTicks := GetTickCount();
  repeat
    Application.ProcessMessages();
    sleep(50);
  until GetTickCount()>= (CountTicks+5500);
  Memo1.Lines.Append(' процедура таймера, запущенная в '+TimeToStr(dt)+
                      ' завершёна в '+TimeToStr(now));
  isInTimer1 := false;
end;

вот за такой код можно не опасаться и в режиме 24/365


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