Вниз
Скачать: CL | DM;

Независимый Timer   Найти похожие ветки 

← →
Yuri Btr ©   (2002-07-03 11:28) [0]

Ув. мастера как сделать так, чтобы Timer в моей программе не тормозился при больших вычислениях. Очевидно вынести его в отдельный поток?
Такой вопрос где то уже задавался, но к сожалению не могу его найти. Заранее спасибо.


← →
Skier ©   (2002-07-03 11:33) [1]

>Yuri Bt
А Application.ProcessMessages не спасёт гиганта мысли и
отца русской демократии ? :)


← →
Fiend ©   (2002-07-03 11:33) [2]

точно.
или найди в инэте, где то есть компонент TThreadTimer


← →
Yuri Btr ©   (2002-07-03 11:40) [3]

to Skier
Application.ProcessMessages не всегда помогает. К тому же отставание всё равно будет. Т.к. невозможно позасовывать Application.ProcessMessages в каждую паузу между операторами.

to Fiend
К сожалению мне нужно использовать только стандартные компоненты Delhi. Я где то видел как это делается руками над простым TTimer


← →
Skier ©   (2002-07-03 11:45) [4]

>Yuri Btr
Посмотри Bluecave Components v.1.0.0 (с исходными текстами)
http://www.torry.net/middle.htm


← →
T2 ©   (2002-07-03 11:59) [5]

Можно привязываться к системному времени или к тикам.


← →
Yuri Btr ©   (2002-07-03 13:11) [6]

Ну что, больше идей нет?
Я просмотрел несколько компонент - таймеров, которые позволяют задать приоритет, но они все почти одинаково работают...
Пожалуйста, мастера помогите!


← →
qube ©   (2002-07-03 14:01) [7]

Логичнее не таймер засунуть в отдельный поток, а большие вычисления. Лезешь в New/Thread Object, и в созданном классе все свои большие вычисления реализуешь в методе Execute.


← →
Yuri Btr ©   (2002-07-03 14:05) [8]

to qube
В ообщем то логичное предложение, но дело в том, что у меня на форме присутствуют в разных местах ListBox"ы и надо добавлять в них много Items (при этом прога тормозится). Для этого не очень удобно использовать Threads.


← →
Digitman ©   (2002-07-03 14:07) [9]

>Yuri Btr

<qube> прав на все 100%. Прислушайся к его совету. Осн. поток, который должен как можно оперативней реагировать на таймерные события, должен быть избавлен от длительных (сравнимых по времени с периодом таймера) вычислительных алгоритмов, стартующих в контексте неких событий/сообщений, обрабатываемых в этом же (основном) потоке.


← →
qube ©   (2002-07-03 14:52) [10]

Большие вычисления -- это одно, а обновление элементов управления на форме -- это совсем другое. Нельзя производить обработку событий в одном потоке, при этом обновляя содержимое листбоксов в другом потоке, могут возникнуть непредсказуемые трудноуловимые глюки. Оптимизируй код. Вместо Listbox.Items.Add в цикле попробуй так:

var
NewItems: TStrings;
begin
NewItems := TStringList.Create;
... // добавляем в NewItems нужные элементы
ListBox.Items := NewItems;
NewItems.Free;
end;


← →
Yuri Btr ©   (2002-07-03 15:05) [11]

to qube, to Digitman
Большое вам спасибо за дельные советы.
Действительно оптимизация дала положительный результат - наверно этим мы просто избавили ListBox прорисовывать лишний раз новые Items.



Страницы: 1 вся ветка

Скачать: CL | DM;



Память: 0.47 MB
Время: 0.008 c
3-47121
Molodoy_Od
2002-06-15 21:45
2002.07.15
Сводные таблицы в InterBase


1-47298
TPavel
2002-06-30 22:41
2002.07.15
Открытие чужой программы.


14-47780
Big Daddy
2002-06-14 15:23
2002.07.15
Прозрачность в Linuxe


1-47380
skarm
2002-07-02 11:00
2002.07.15
интерфейс


3-47231
Андрусь
2002-06-18 11:27
2002.07.15
Регулировка закачки данных




   Наверх