Timer

← →
Anatoly P (2003-10-15 19:35) [0]

Есть массив динамически созданных таймеров, на .OnTimer хочу уничтожить, как правильно это сделать (пробовал .Free, .Destroy)?

← →
Юрий Федоров (2003-10-15 19:44) [1]

уничтожить кого ?
PS
Free от Destroy отличается только тем, что в Free производится проверка на nil (см. реализацию в System.pas)

← →
Palladin (2003-10-15 19:44) [2]

А что говорит по этому поводу справка?

← →
Anatoly P (2003-10-15 19:46) [3]

Уничтожить себя после выполнения возложенной задачи

← →
Rouse_ (2003-10-15 19:47) [4]

А что нужно удалить то? Таймер из массива или массив?

Желаю успехов

ЗЫ: > (пробовал .Free, .Destroy) - И не получается?

← →
Anatoly P (2003-10-15 19:50) [5]

Уничтожить таймер после того как он выполнил .OnTimer

← →
Rouse_ (2003-10-15 19:51) [6]

> Уничтожить себя после выполнения возложенной задачи :))
Терминатор - 4 блин, не в обиду :))

ЗЫ: Сори за оффтопик

← →
Anatoly P (2003-10-15 19:53) [7]

Ну одноразовый :)

← →
Кулюкин Олег (2003-10-15 19:54) [8]

Из обработчика события лучше не уничтожать объект, которому это событие принадлежит.
Посылайте форме сообщение, пусть она уничтожает таймеры.

А что за надобность пладить массив таймеров?
Сдается мне, криво это как-то.

← →
Anatoly P (2003-10-15 19:56) [9]

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

← →
Rouse_ (2003-10-15 19:59) [10]

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

Желаю успехов

← →
Кулюкин Олег (2003-10-15 19:59) [11]

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

← →
Кулюкин Олег (2003-10-15 20:00) [12]

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

А еще лучше, потоки.
Которые сами себы будут уничтожать
см. TThread.FreeOnTerminate

← →
Юрий Зотов (2003-10-15 20:02) [13]

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

var
Timers: TObjectList;

procedure TForm1.AllTimersOnTimer(Sender: TObject);
begin
PostMessage(Handle, WM_USER + 100, Integer(Sender), 0)
end;

procedure TForm1.WMUserPlus100(var Message: TMessage);
begin
Timers.Remove(TObject(Message.WParam))
end;

← →
Rouse_ (2003-10-15 20:06) [14]

> Юрий Зотов © (15.10.03 20:02) [13]
Так то оно так, но если делать на апи, то не будет расходоваться память под экземпляр класса. Как никак а оптимизация :))

Желаю успехов

← →
Юрий Зотов (2003-10-15 20:08) [15]

> Rouse_ © (15.10.03 20:06) [14]

А если написать на API всю программу, то оптимизация будет еще сильнее.

Вот только оптимизация ЧЕГО?
:о)

← →
Rouse_ (2003-10-15 20:15) [16]

SetTimer(FHandle, <ИДЕНТИФИКАТОР>, 1000, nil);
и на WM_TIMER будем определять <ИДЕНТИФИКАТОР> по WParam, затем выполняем ему KillTimer.
Никакого массива, никаких проблем с классами и событиями. Ведь кажется ваши слова были что лучше пользоваться тем что давно уже придумано, а не делать свои велосипеды?

Желаю успехов

← →
Кулюкин Олег (2003-10-15 20:20) [17]

← →
Юрий Зотов (2003-10-15 20:23) [18]

> лучше пользоваться тем что давно уже придумано, а не делать
> свои велосипеды?

Именно так. Как раз поэтому есть смысл использовать TTimer, раз уж используется форма.

← →
Rouse_ (2003-10-15 20:26) [19]

Хорошо, согласен с вами обоими, но в плане эффективности использования памяти мой вариант более эффективен. Думаю это нельзя отрицать.

Желаю успехов

← →
Юрий Зотов (2003-10-15 20:28) [20]

Никто и не отрицает. Но... см. [15].

← →
Rouse_ (2003-10-15 20:34) [21]

Просто во мне, как всегда, опять заговорил старый фанат АПИ ;)
и при постановке мне данной задачи, я бы выполнил ее именно так. Просто привык проводить оптимизацию кода еще в момент написания самого кода.

Желаю успехов.

← →
Palladin (2003-10-15 20:41) [22]

Лучше задуматся, а нужны ли эти несколько таймеров, и можно ли обойтись одним.

← →
Rouse_ (2003-10-15 20:50) [23]

Timer Найти похожие ветки