Здравствуйте, butcha, Вы писали:
B>Гарантировать должен программист, вызывать её только при "lengthy operations" в основном потоке, обеспечивая модальный режим, при котором невозможно предпринимать никакие другие действия со стороны пользователя, но иметь возможность корректно среагировать к примеру на принудительное завершение, выключение виндовс ...
Вот так бы сразу. А теперь вот что: в хелпе это есть? Именно эти пункты в явном виде.. Нет. Программисты используют эту функцию не только для этого? Не только. Программы глючат? Глючат. Так что мое предупреждение в силе. Но, очевидно, я не постиг дао ProcessMessages до конца — вполне может быть, что в модальных окнах, не содержащих лишних возможностей интерактива, ProcessMessages будет оправдан. По крайней мере, сейчас с ходу я не могу придумать сильный контраргумент. Возможно, правильнее действительно не советовать отказываться от ProcessMessages, а предложить вот такой вот ваш сценарий использования этого метода. Жаль, что мне он не пришел в голову, когда я писал статью.
Впрочем, вот написал я это, а сейчас зарегистрировал в программе RegisterHotkey, и, находясь в модальном окне (и даже конкретно в "repeat Application.ProcessMessages() until false"), вполне себе радостно нажал кнопочки и вуаля — хоткей сработал. И большой вопрос, насколько ваш главный поток (занятый сейчас какой-то длительной работой) реентерабелен — насколько консистентно его состояние последи операции. Если б вы для индикации хода выполнения использовали отдельный поток с отдельным окном (например), хоткей бы не сработал при занятом главном потоке и не вмешался бы в ход длительной операции.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Впрочем, вот написал я это, а сейчас зарегистрировал в программе RegisterHotkey, и, находясь в модальном окне (и даже конкретно в "repeat Application.ProcessMessages() until false"), вполне себе радостно нажал кнопочки и вуаля — хоткей сработал.
Если такое поведение в реальной программе приведет к проблемам, полагаю, вменяемый программист додумается завести признак выполнения длительной операции и проверять его. Это не бином Ньютона. То есть я к тому, что ProcessMessages не настолько опасен, чтобы ограждать от него новичков. Но сообщить всем об особенностях — правильно.
P.S. По-моему, 95% случаев реального применения ProcessMessages — это splash-screen при старте. И там он вполне безопасен (исключая экзотические случаи спама сообщениями от посторонних программ). Если же длительная операция запускается в середине сеанса работы, и пользователю нужно дать возможность сделать что-то еще — тут уж придется выделять ее в отдельный поток, вариантов нет.
Здравствуйте, Slicer [Mirkwood], Вы писали:
SM>Вот так бы сразу. А теперь вот что: в хелпе это есть? Именно эти пункты в явном виде.. Нет.
Вот хелп как раз и есть одно из "Неудачных решений" в дельфи после дельфи7. Там практически ничего не стало, лишь одни автоматические статьи-заглушки с перечислением параметров функций, как будто их без хелпа не видно.
SM>Впрочем, вот написал я это, а сейчас зарегистрировал в программе RegisterHotkey, и, находясь в модальном окне (и даже конкретно в "repeat Application.ProcessMessages() until false"), вполне себе радостно нажал кнопочки и вуаля — хоткей сработал. И большой вопрос, насколько ваш главный поток (занятый сейчас какой-то длительной работой) реентерабелен — насколько консистентно его состояние последи операции. Если б вы для индикации хода выполнения использовали отдельный поток с отдельным окном (например), хоткей бы не сработал при занятом главном потоке и не вмешался бы в ход длительной операции.
Всё это легко решается, напр. ставятся запрещающие флажки на время нежелания исполнения комманд.
Главный поток во время исполнения Hotkey будет находится внутри Application.ProcessMessages, ну а где она вызывается, вы будете прекрасно знать.
Здравствуйте, Jack128, Вы писали: J>вовод то из всего этого какой?? Что использовать вместо ProcessMessages ?? А вот черт его знает. Я хорошего ответа не нашел, по кр. мере, который бы учитывал потребности задач, которые у меня возникали. Но вот люди же здесь советуют варианты — которые делают косяки менее вероятными. Возможно, во многих ситуациях таких решений будет достаточно — в конце концов, не все приложения регистрируют, например, горячие клавиши.
Еще в принципе можно самостоятельно организовать цикл выборки сообщений — с указанием нужных флагов в PeekMessage, например, т.е. не всех подряд, а, скажем, только о перерисовке. Хотя это тоже чревато тем, что (из-за изменения порядка обработки сообщений в очереди) что-то сломается, пусть вероятность этого и невелика. А вообще, может, это и нормально, я этот вопрос подробно не исследовал.
Ну и еще можно длительный процесс вынести в отдельный поток (это часто несложно, но становится куда сложнее, если поток как-то использует окна, да и не только — вон в XE3 у меня даже создавать некоторые объекты картинок в отдельном потоке не получалось). У нас же, к примеру, было принято довольно извращенное решение — мы вынесли индикацию прогресса в отдельный поток =) проблему отрисовки главного окна это, конечно, не решило, зато пользователь мог видеть, что приложение не зависло. Но в этом потоке пришлось окошко (для индикации работы) полностью реализовать средствами Windows API.
Slicer
Специалист — это варвар, невежество которого не всесторонне :)
А вот черт его знает. Я хорошего ответа не нашел, по кр. мере, который бы учитывал потребности задач, которые у меня возникали. Но вот люди же здесь советуют варианты — которые делают косяки менее вероятными. Возможно, во многих ситуациях таких решений будет достаточно — в конце концов, не все приложения регистрируют, например, горячие клавиши.
