Application processmessages delphi что это
Application processmessages delphi что это
Метод Application.ProcessMessages необходимо применять в динамичных приложениях, требующих немедленного отображения выполненных в программе действий. Для повышения быстродействия программы сообщения (Messages!), которые объект Application посылает объектам программы, этими объектами выполняются не сразу после получения, а по мере накопления некоторой очереди.
Для иллюстрации работы метода Application.ProcessMessages рассмотрим процедуру, троекратным «мельканием» текста в строке ввода обращающего внимание пользователя на то, что данные не введены:
Аналогично, программа, выполняющая длительные вычисления, может выглядеть зависшей, так как даже сообщения на перемещение её окна или нажатия на кнопки не будут обработаны, пока вычисления не будут закончены. Поэтому нужно либо выполнять вычисления в отдельном потоке, либо периодически выполнять Application.ProcessMessages. Однако, в этом случае нужно учитывать, что выполнение этого метода несколько тормозит выполнение программы, и его вызов не должен быть слишком частым.
Другой пример, связанный с работой с графикой в Delphi. Динамика построения графиков функций, когда график рисуется постепенно, по мере вычисления очередной точки, выглядит в программе очень эффектно. Чтобы добиться такого эффекта, также необходимо применять метод Application.ProcessMessages. Вычисляя положение очередной точки, нужно после её выведения на холст:
Canvas.LineTo(X[n], Y[n]);
sleep(200);
Без применения последнего оператора мы получим сразу готовый график функции, и даже применение оператора задержки перед выводом очередной точки не поможет.
Application processmessages delphi что это
Метод Application.ProcessMessages необходимо применять в динамичных приложениях, требующих немедленного отображения выполненных в программе действий. Для повышения быстродействия программы сообщения (Messages!), которые объект Application посылает объектам программы, этими объектами выполняются не сразу после получения, а по мере накопления некоторой очереди.
Для иллюстрации работы метода Application.ProcessMessages рассмотрим процедуру, троекратным «мельканием» текста в строке ввода обращающего внимание пользователя на то, что данные не введены:
Аналогично, программа, выполняющая длительные вычисления, может выглядеть зависшей, так как даже сообщения на перемещение её окна или нажатия на кнопки не будут обработаны, пока вычисления не будут закончены. Поэтому нужно либо выполнять вычисления в отдельном потоке, либо периодически выполнять Application.ProcessMessages. Однако, в этом случае нужно учитывать, что выполнение этого метода несколько тормозит выполнение программы, и его вызов не должен быть слишком частым.
Другой пример, связанный с работой с графикой в Delphi. Динамика построения графиков функций, когда график рисуется постепенно, по мере вычисления очередной точки, выглядит в программе очень эффектно. Чтобы добиться такого эффекта, также необходимо применять метод Application.ProcessMessages. Вычисляя положение очередной точки, нужно после её выведения на холст:
Canvas.LineTo(X[n], Y[n]);
sleep(200);
Без применения последнего оператора мы получим сразу готовый график функции, и даже применение оператора задержки перед выводом очередной точки не поможет.
Application processmessages delphi что это
Недавно прочитал в какой-то статье, посвященной программированию в среде Delphi, что в нормальном приложении Application.ProcessMessages вообще не должно быть. Видимо, имелось в виду, что нужно обходиться другими методами. Как бы вы прокомментировали это?
← →
MBo ( 2004-01-06 18:44 ) [1]
← →
YuRock ( 2004-01-06 18:49 ) [2]
ProcessMessages используется при необходимости выкрутить сообщения. При чем здесь «нормальное приложение», не понятно.
← →
Тимохов ( 2004-01-06 18:50 ) [3]
Скажу по своему опыту, что Application.ProcessMessages чрезвычайно вредная вешь при навернутой программе. Иногда бывают такие фокусы, что не сразу разберешь, что к чему.
Но все равно использую, т.к. пока нет времени разнести все по потокам.
← →
jack128 ( 2004-01-06 19:00 ) [4]
Чем проще программа, тем лудше использовать Application.ProcessMessages, ибо нефиг излишне усложнять программу потоками.
jack128 © (06.01.04 19:00) [4]
ProcessMessages все-таки коварная штука.
Чессо слово тяжело сейчас строить пример, несмотря на то, что я его хорошо помню. Но уверен, что некоторое время он любого вы ввел в заблуждение.
Сухой остаток: юзать можно, но осторожно.
← →
ИМХО ( 2004-01-06 19:02 ) [6]
А как это делать (насчет отдельных потоков)?
Я, например, использую Application.ProcessMessages для того, чтобы отображались показания таймера во время работы какой-то процедуры.
← →
Vlad ( 2004-01-06 19:11 ) [7]
TThread + F1.
И еще в FAQ есть кое какая инфа, даже с кодом.
← →
jack128 ( 2004-01-06 19:39 ) [8]
>
> Тимохов © (06.01.04 19:02) [5]
> jack128 © (06.01.04 19:00) [4]
>
> ProcessMessages все-таки коварная штука.
> Чессо слово тяжело сейчас строить пример, несмотря на то,
> что я его хорошо помню. Но уверен, что некоторое время он
> любого вы ввел в заблуждение.
Думаю пример был бы в том что несколько обработчиков сообщений изменяют одну и туже глобальную переменную.
например
var
obj: TMyClass = nil;
procedure TForm1.Button2Click(Sender: TObject);
begin
FreeAndNil(obj);
end;
procedure TForm1.FormCreate(Sender: TObject);
begin
obj := TMyClass.Create;
end;
← →
Anatoly Podgoretsky ( 2004-01-06 19:49 ) [9]
Ну и какое отношение это глюкавый код имеет к якобы глюкавому Application.BrocessMessages.
Авторы хотят выглядеть святее, чем Папа Римский.
Так что читать такие статьи лучше с включенной головой.
← →
jack128 ( 2004-01-06 19:52 ) [11]
> Anatoly Podgoretsky © (06.01.04 19:49) [9]
> Ну и какое отношение это глюкавый код имеет к якобы глюкавому
> Application.BrocessMessages.
Да водщем то никакого. Это доказательство того, что имея достаточно кривые руки можно написать глюкавый код в пять строк 😉
← →
Тимохов ( 2004-01-06 19:54 ) [12]
Игорь Шевченко © (06.01.04 19:49) [10]
Немного грубовато имхо.
Всем.
в [8] есть пример ошибки. Может случить там, что obj отдестроиться, когда цикл еще не кончился.
У меня действительно была схожая ситуация, только такм был не цикл, а рекурсия.
jack128
Ценю проницательность 🙂
← →
Anatoly Podgoretsky ( 2004-01-06 19:55 ) [13]
Конечно можно, но почти тотже код без Application.BrocessMessages даст тот же самый результат.
procedure TForm1.Button1Click(Sender: TObject);
begin
obj.SameMethod;
// нажать вторую кнопку, затем первую
← →
Тимохов ( 2004-01-06 19:56 ) [14]
Anatoly Podgoretsky © (06.01.04 19:49) [9]
И вообще никто не говорил, что processmessages имеет глюки.
Просто он таит в себе определенные опасности при кривых, как было сказано выше, руках.
Anatoly Podgoretsky © (06.01.04 19:55) [13]
Думаю все-таки ясно в чем была суть примера. ИМХО Вы издеваетесь. 🙂
← →
Anatoly Podgoretsky ( 2004-01-06 19:58 ) [16]
← →
Тимохов ( 2004-01-06 20:01 ) [17]
Anatoly Podgoretsky © (06.01.04 19:58) [16]
Думаю надо согласиться на том, что данный пример подразумевает нажатие сначала первой кнопки. И пока там идет while нажатие второй кнопки. Думаю, что пример обладает некой недоделанностью. Но суть обсуждаемого вопроса показывает полностью.
← →
Anatoly Podgoretsky ( 2004-01-06 20:10 ) [18]
Показывает только безобразно написаный код и не более.
← →
Игорь Шевченко ( 2004-01-06 20:12 ) [19]
Тимохов © (06.01.04 19:56)
> никто не говорил, что processmessages имеет глюки.
> Просто он таит в себе определенные опасности при кривых,
> как было сказано выше, руках.
А при кривых руках, уважаемый, на помощь приходит выпрямитель рук, называемый отладчиком или WinSight»ом(для просмотра сообщений). Если вы молотком по пальцу попадете, забивая гвоздь, вы же не станете писать статью о вреде использования молотка 😉
← →
Тимохов ( 2004-01-06 20:27 ) [20]
Игорь Шевченко © (06.01.04 20:12) [19]
Anatoly Podgoretsky © (06.01.04 20:10) [18]
Ладно, чтобы пояснить свою мысль прведу свой код.
Есть SomeAction выполняемая по клавише F5.
Пользователь нажимает на эту клавишу в течении одной минуты. Потом сразу нажимает крестик в углу форма (т.е. close)
Вот упрощенный код.
procedure tform1.SomeActionExecute(. )
begin
if SomeHeavyDatabaseQuery <> nil then
begin
Application.ProcessMessages();
SomeHeavyDatabaseQuery.Execute();
end;
end;
destructor tform1.Destroy();
begin
FreeAndNil(SomeHeavyDatabaseQuery);
end;
Что здесь происходит.
Когда пользователь жмет f5, то прога может дойти до Application.ProcessMessages(). После чего не пойдет дальше а снова попадет в этот же обработчик. И так раз сто. При этом образуется полноценный (т.е. дельфовый, а не ивентный) стек вызовов. Когда пользователь вызывает close, то он делается releasom, т.е. тоже через посыл сообщения. Этот ивент радостно отрабатывает, после чего выполнение программы возвращается на строку SomeHeavyDatabaseQuery.Execute(). Здесь и происходит АВ.
В примере можно задать не запрос, а любое занимающее время действие с обращением к полям объекта.
В описанной ситуации будет ошибка. Ясно, что это ошибка программиста, но все же она не вполне очевидна.
← →
Бином Ньютоныч ( 2004-01-06 20:40 ) [21]
>нормальном приложении Application.ProcessMessages вообще не должно быть.
← →
Anatoly Podgoretsky ( 2004-01-06 20:55 ) [22]
Она вполне очевидна, неверная последовательность операторов, если же нужна именно эта последовательность, то проверять надо после Application.ProcessMessages(); иначе получается некоторая самоуверенность, попытка использования переменной или поля с непредсказуемым содержимым.
Кривые руки никак не доказывают недостатков Application.ProcessMessages, народ умудряется работать с объектами вообще их не создавая. Данный метод ни чем не хуже других неверно используемых средств. Сам метод как раз и предусмотрен, чтобы обработать сообщения системы, еще с времен Windows 1.0, а многозадачная среда накладывает свой отпечаток.
← →
Anatoly Podgoretsky ( 2004-01-06 20:58 ) [23]
Бином Ньютоныч (06.01.04 20:40) [21]
Ресурсоемкость да бог с ней, а вот с потоками столько ошибок наделают, что всю систему на колени поставят. Потоки нужны для выполнения паралельной работы.вычислений, но никак не для обработки сообщений.
← →
Бином Ньютоныч ( 2004-01-06 21:13 ) [24]
>Anatoly Podgoretsky © (06.01.04 20:58) [23]
Ну вообще-то я имел в виду вариант с выносом ожидания в отдельный поток:) В смысле вовсе не всегда это оптимально
← →
Anatoly Podgoretsky ( 2004-01-06 21:22 ) [25]
Конечно не оптимально, если другие потоки не будут делать полезную работу, а что бы двигать форму, нажимать на ней кнопки нет нужды их делать.
← →
Тимохов ( 2004-01-08 11:26 ) [26]
Но, все-таки хочется подвести итог данному обсуждению.
Исходный вопрос автора был о нашем отношении к высказыванию некого автора некой статьи о том, что ProcessMessages вообще быть не должно.
← →
Игорь Шевченко ( 2004-01-08 12:14 ) [27]
Тимохов © (08.01.04 11:26)
> использовать ProcessMessages можно, но осторожно
← →
Тимохов ( 2004-01-08 12:19 ) [28]
Игорь Шевченко © (08.01.04 12:14) [27]
Смешного ничего здесь не вижу.
И вообще, обещаю, что в следующий раз при обсуждении не вполне очевидного момента после приведения ошибочного кода не буду давать комментарий почему он ошибочен. Интересно, сдюжат ли мастера прорюхать что к чему? :)))
И вообще, все, что нужно по данному вопросу счию уже сказано.
← →
int64 ( 2004-01-09 12:17 ) [29]
А вы знаете, что левые повороты опаснее правых.
А двигаться на лево можно комбинируя прямо и право.
Вот об этом и весь разговор: о преймуществе второго метода. 🙂
← →
BlackTiger ( 2004-01-09 16:20 ) [30]
Чёй-то вы фигней тут, имхо, занимаетесь. ProcessMessages использовать НУЖНО, но только там, где нужно. Сколько раз мне помогал его VB-аналог «DoEvents»!
Он помогает НЕ ЗАВЕШИВАТЬ приложение (точнее его интерфейс) при большом количестве итераций или при медленных итерациях в цикле.
← →
Тимохов ( 2004-01-09 16:27 ) [31]
BlackTiger © (09.01.04 16:20) [30]
Про «занимаетесь фигней», имхо считаю, что Вы не тактичны. Считаю, что скорее фигней занимаетесь Вы т.к. повотрили неоднократно выше приведенное утверждение.
← →
Fantasist ( 2004-01-10 02:27 ) [32]
> использовать ProcessMessages можно, но осторожно.
Использовать потоки можно, но осторожно. Использовать RPC
можно, но осторожно. Использовать dll»ки можно, но осторожно.
Программировать можно, но осторожно. Ибо проблему можно создать везде, если не понимаешь с чем работаешь.
← →
olookin ( 2004-01-10 10:26 ) [33]
(а почему ветка до сих пор не в Потрепаться? «Последняя половина» сообщений принимает характер личного обсуждения. )
← →
Вован_ ( 2004-01-10 12:01 ) [34]
Я не понимаю, какое приложение.ProcessMessages в Delphi делает [закрыто]
Я noobie в Delphi, так что извините за возможные глупые вопросы.
мой руководитель объяснил мне это приложение.ProcessMessages предотвращает замораживание приложения и выделяет дополнительное вычислительное время. Но в документах этой команды всегда что-то объясняется о системе очередей, которая обрабатывается? Пожалуйста, кто-нибудь может объяснить мне контекст?
2 ответов
нет короткого способа ответить на этот вопрос правильно.
основным средством взаимодействия приложений Windows с операционной системой является система обмена сообщениями. Все, что происходит в приложении windows, происходит в ответ на сообщение.
например :
если вы нажмете на экран, операционная система решит, какое приложение было нажато, и опубликует сообщение этому приложению, указывающее, что оно получил щелчок (вместе с местоположением этого щелчка).
если окно перемещается и показывает часть вашего приложения под ним, операционная система отправляет сообщение о том, что ваше приложение перекрашивается.
список продолжается. Все, что происходит, управляется сообщениями.
Проблема
вы приходите и начинаете писать заявление. Вы можете написать такой код:
в большей структуре программы выполнение в основном потоке выглядит следующим образом:
таким образом, этот цикл счастливо wizzing, когда внезапно один из связанных обработчиков ( Button1Click выше) начинает принимать очень длительное время. ключ к пониманию заключается в том, что один обработчик сообщений должен завершиться до запуска следующего. если вы, например, щелкните полосу прокрутки и перетащите ее, но вы прикрепили обработчик к OnClick полосы прокрутки, которая занимает 10s для завершения, затем перетащите операция не будет видна вашим приложением, пока этот обработчик щелчка не завершится. Тем временем очередь сообщений заполняется, и основной поток ничего не делает с этим.
Введите ProcessMessages
ленивое, ужасное решение не помещать ваш длительный код в поток
это может показаться поверхностно, как разумная вещь, чтобы сделать, так как это позволяет держать приложение отзывчивым во время длительного цикла. В конечном счете, однако, этот стиль программирования широко считается чрезвычайно плохой практикой по большому числу очень веских причин. Достаточно сказать, что везде вы испытываете соблазн использовать Application.ProcessMessages является твердым случаем для перемещения этой работы в фоновый поток.
более подробно, давайте посмотрим на фактический код:
поэтому, когда вы делаете этот вызов Application.ProcessMessages вы запускаете цикл, который один за другим очищает сообщения из очереди сообщений (и выполняет весь код, прикрепленный к обработчикам, которые реагируют на эти сообщения), пока он не будет пустым. Когда он пуст и больше нет сообщений для обработки, control вернется к следующей строке в вашей программе.
важный момент, котор нужно принять прочь что жидкость, ровная взаимодействие, которое вы испытываете при использовании программы, является полной иллюзией, которая зависит именно от этого цикла сообщений, обрабатываемого как можно быстрее. Чем меньше временная задержка между сообщением, отправляемым в ваше приложение, и обрабатываемым сообщением, тем больше ваше приложение будет чувствовать себя живым и отзывчивым.
именно по этой причине весь код, прикрепленный к обработчикам пользовательского интерфейса, должен работать быстро. Длительные операции должны быть прервано, чтобы обработка сообщений могла продолжаться (т. е.: Application.ProcessMessages ) или эти операции должны быть перемещены в отдельный поток, где они могут выполняться без привязки основного потока и снятия его с основной ответственности (которая заключается в сохранении пользовательского интерфейса).
для действительно хорошей статьи по этой теме см.:
Одиссея ключа Питер ниже
(ссылка на кэш Google. сервер кажется занятым для меня)
Аннотация: данная статья следует пути сообщения нажатия клавиши через VCL. Вы узнаете, как реализована обработка ключей, как работают события OnKey и какие точки вмешательства для программиста можно найти во всем процессе. Кроме того, объясняются такие вещи, как обработка сообщений, и вы узнаете, как отслеживать сообщения в отладчике из цикла сообщений в конечный пункт назначения.
сообщения
Delphi-это приложение для Windows, и много общения между компонентами Windows (например, формами, полями редактирования, но и скрытыми вещами, такими как таймеры) выполняется с помощью вещей, называемых сообщения.
многие современные операционные системы, управляемые событиями, такими как Windows. На самом деле Delphi VCL обертывает много функций Windows, и многие вещи, которые вы делаете, приведут к отправке сообщений между элементы управления, которые уведомляют эти элементы управления щелчками мыши, нажатиями клавиатуры, изменением настроек Windows, закрытием приложения, перемещением элемента управления и т.д.
Mainthread не обрабатывает сообщения при выполнении кода
операционные системы также позволяют программам, чтобы иметь вещи, называемые потоками. Потоки похожи на небольшие части программы, которые работают одновременно (и в некоторых случаях работают одновременно). Приложение может иметь один или несколько потоков, но всегда есть основной поток, который также отвечает за прием входящих сообщений и обновление GUI.
когда основной поток приложения простаивает (не выполняет код), он проверяет очередь, чтобы увидеть, есть ли сообщения и обработать их. В то время как другой несвязанный код выполняется, this не может произойдет. Рассмотрим следующий пример:
если вы выполняете этот код, вы ожидаете, что метка получит заголовок «A», который меняется на » Б » через пять секунд. Но это не так. Установка заголовка метки вызывает перекраску элемента управления с помощью сообщения. Поскольку основной поток по-прежнему заблокирован этим кодом (даже командой Sleep), сообщение еще не обработано.
только когда прошло 5 секунд и заголовок установлен, основной поток становится бездействующим и выполнит перерисовки, которые мы вызвали, установив заголовок. Также обратите внимание, что другое взаимодействие, например, нажатие кнопки или перетаскивание окна откладывается до истечения 5 секунд. Весь основной поток замерзает.
приложение.ProcessMessages на помощь
приложение.ProcessMessages просто заставит приложение очистить свою очередь сообщений, поэтому вы можете «исправить» код следующим образом:
обычно в вашем коде не будет просто сна, но много фактической обработки. Используя Application.ProcessMessage часто, вы можете сохранить интерфейс приложение отвечает, даже когда вы выполняете код.
Итак, документы, которые Вы читаете, правы: Application.ProcessMessages будет пустой сообщение очередь. Ваш начальник не совсем прав. Он не выделяет дополнительное время на обработку, но он просто интегрирует опорожнение очереди сообщений в выполняемый код, в то время как обычно сообщения остаются в очереди до тех пор, пока приложение не станет простаивать.
внутреннее устройство
это обработка, которая выполняет код, например, если WM_MOUSECLICK сообщение обработано, оно вызовет (через некоторую магию Delphi VCL), ваш Button1Click обработчик событий. Поскольку это один поток, все работает последовательно, поэтому вы поймете, что ProcessMessageFromTheQueue возвращается только после завершения обработчика событий. Delphi обрабатывает только одно сообщение за раз, и только делает следующее, когда обработка предыдущего завершена.
Application.ProcessMessages выглядит так:
таким образом, он делает почти то же самое, что и основной цикл приложения: он выбирает сообщение из очереди и обрабатывает его. Таким образом, это означает, что вы можете обрабатывать следующие сообщения, пока вы находитесь внутри обработки последнего. Удобный трюк, но он может легко сделать ваше приложение грязным.
правильный путь: потоки
большинство людей считают, что это лучшее решение для использования отдельный поток для выполнения кода и просто отправлять сигналы в основной поток, когда ему нужно обновить метку или индикатор выполнения. Таким образом, основной поток все время простаивает и будет продолжать отвечать на щелчки мыши и т. д.
Threading трудно для новичка, хотя. Некоторые вещи, чтобы иметь в виду: