Latest post of the previous page:
все задачи с таймерами можно разбить на две группы: где важно количество вызовов и где не важно. текущая реализация работает и там и там. то, что предлагаете вы - работает лишь со второй группой.far.Timer
- John Doe
- Бюрократ
- Posts: 13867
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
far.Timer
Именно, потому что задач первой группы не смог придумать ни одной.
Выше спрашивал, никто тоже не подсказал.
Впрочем, даже с моим предложением можно решить те гипотетические задачи, вычисляя количество пропущенных итераций делением времени, прошедшее с последнего вызова, на период таймера.
- HaRT
- Moderator
- Posts: 10869
- Joined: Tue 30 Aug, 2005 17:21
- Has thanked: 221 times
- Been thanked: 358 times
far.Timer
Альтернативное решение — объединение одинаковых событий во входной очереди (разумеется, со счётчиком). Разумеется, должны ли события данного типа объединяться, следует решать для каждого типа отдельно. Например, события таймера или автоповторы нажатой клавиши, вероятно, стоило бы объединять.
Фар есть инструмент, а не нянька. © 2009 DrKnS
- John Doe
- Бюрократ
- Posts: 13867
- Joined: Wed 27 Apr, 2005 20:42
- Has thanked: 74 times
- Been thanked: 428 times
- Contact:
far.Timer
Да, так тоже можно.
Применительно к far.Timer, счётчик событий может быть вторым аргументом функции-хэндлера, либо свойством объекта timer.
И это можно, например методом объекта таймер.
Только не соглашусь с формулировкой "Разумеется". Да, это было бы наиболее универсально, и волкам и овцам.
Но нужно ли?
Возможно я не вижу всей картины, но похоже что задачи "первого" типа в реальной практике у нас встречаются редко (надеюсь кто-нибудь хоть один реальный пример приведёт, чтобы было о чём говорить.)
Предлагаемое изменение ещё в изначальной формулировке упростит работу с задачами "второго" типа, при этом (как мне пока кажется) сохранив возможность работы с задачами "первого" типа, хоть и не так удобно.