Устройство TApplication

← →
Piter © (2004-11-08 15:18) [0]

TApplication производит выборку сообщений с помощью PeekMessage, очевидно из-за того, чтобы не "зависнуть", если сообщений нет. Делается это так, чтобы генерировать OnIdle в отсутствии сообщений и производить некий UpdateActions (для чего - я пока не понял). В связи с чем у меня возникает вопрос - а почему Дельфовое приложение не начинает занимать все свободное время процессора? Ведь всегда есть чем заняться - крутиться бесконечный цикл вызовов HandleMessage.

Я понимаю с GetMessage - если сообщений нету, то поток приостанавливается. Я даже думаю он вообще из планирования исключается до прихода сообщений. А тут как умудряется все работать?

P.S. И побочный вопрос - а нафига реализовано TApplication.ProcessMessages ? Вроде его вызовов нигде нету...

← →
KilkennyCat © (2004-11-08 15:21) [1]

а может, все наоборот? не приложение хочет, а ему разрешают? :)

← →
Piter © (2004-11-08 15:24) [2]

KilkennyCat © (08.11.04 15:21) [1]

не понял

← →
Sandman25 © (2004-11-08 15:32) [3]

UpdateActions - это вызов обработчка OnUpdate у различный TAction, TActionList и т.д.

Дельфовое приложение не начинает занимать все свободное время процессора?

procedure TApplication.Idle(const Msg: TMsg);
begin
...
if Done then WaitMessage; // вот оно - ожидание!
end;

TApplication.ProcessMessages вызывается клиентским кодом.

← →
KilkennyCat © (2004-11-08 15:34) [4]

я просто думал всегда, что OnIdle генерируется в приложение, а не в приложении...

← →
KilkennyCat © (2004-11-08 15:37) [5]

я не прав. пойду спать.

← →
Ihor Osov'yak © (2004-11-08 15:41) [6]

> а почему Дельфовое приложение не начинает занимать все свободное время процессора? Ведь всегда есть чем заняться - крутиться бесконечный цикл вызовов HandleMessage.

Внимательно смотреть TApplication.Idle. Может повезет, и заметите строчку
if Done then WaitMessage;
===

> TApplication.ProcessMessages

Для организации обработки очереди сообщений в процессе длительной работы какого-то обработчика (во избежание "замораживания" интерфейса).
Использование чревато очень многочисленными граблями в случае непонимания происходящих процессов вокруг очереди сообщений. К сожелению, такое непонимание очень часто наблюдается. Воинствующее непонимание.

← →
Piter © (2004-11-08 16:01) [7]

Удалено модератором

← →
Piter © (2004-11-08 16:18) [8]

Sandman25 © (08.11.04 15:32) [3]
TApplication.ProcessMessages вызывается клиентским кодом

торможу-у-у...

← →
Ihor Osov'yak © (2004-11-08 16:37) [9]

Удалено модератором

← →
Sandman25 © (2004-11-08 16:42) [10]

[8] Piter © (08.11.04 16:18)

В [6] хорошо рассказано. В обработчике нажатия кнопки выполняются длительные расчеты. Чтобы форма не выглядела подвисшей, периодически из цикла расчетов вызывается отрисовка форм приложения. Application.ProcessMessages вполне подойдет вместо Form1.Update, Form2.Update и т.д.

← →
Anatoly Podgoretsky © (2004-11-08 16:50) [11]

Sandman25 © (08.11.04 16:42) [10]
Только не отрисовка, а опрос наличия сообщений и если они есть, то они обрабатываются.

[11] Anatoly Podgoretsky © (08.11.04 16:50)

Конечно. Поэтому следует сделать Enabled := False тем контролам, которые должны быть недоступны, пока не закончатся вычисления.

Удалено модератором
Примечание: Выяснениние отношений надо делать в частной переписке, а не в форуме, остальным это не интересно

>>Piter © (08.11.04 18:11) [13]

procedure TForm1.Button1Click(Sender: TObject); var I: Integer; begin for I := 1 to 30 do begin Sleep(1000); Application.ProcessMessages; end; end;

Даже лучше так:

procedure TForm1.Button1Click(Sender: TObject); var I: Integer; begin for I := 1 to 30 do begin Sleep(1000); Application.ProcessMessages; if Application.Terminated then Exit; end; end;

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

В любом случае, ответ на вопрос я понял, не заметил WaitMessage...

Устройство TApplication Найти похожие ветки