Delphi + WinApi

← →
KSergey (2004-02-11 10:49) [40]

> [39] jack128 © (11.02.04 09:44)
> Упрощенно ShowModal выглядит так
> WndList := DisableTaskWindows(0);//

Да теперь я тоже это знаю ;)
Но до того вот до этих DisableTaskWindows/EnableTaskWindows я и не догадывался!
Ранее же я думал, что в цикле обработки сообщений, организуемого внутри ShowModal, сообщения, предназначенные другим окнам, просто фильтруются хитрым образом, дабы не пропустить сообщения от клавы/мыши или еще чего-то там, чтобы эти окна не активизировались.
А все оказалось проще: запретил их все - и пусть уже система разбирается как им не дать активизироваться ;)

← →
KSergey (2004-02-11 10:55) [41]

> [39] jack128 © (11.02.04 09:44)
> Но к вопросу автора, как мне кажется, это не какого отнашения не имеет ;-)

А по-моему, очень даже имеет.
Собственно взялся я за сей опус лишь потому, что автор предполагал, что все проблемы кроются как раз в VCL, и применив мистическое WinAPI, где все хорошо и здорово, от проблем удасться избавиться очень легко и просто (см. первый пост с вопросом).
Вот я и попытался подробно показать, что ничего от этого не изменится.
Более того, я усмотрел в вопросе автора надежду на то, что описанный мною метод "через жопу", который, как мне показалось, и ему казался панацей и который в общих чертах он тоже описывал (как мне показалось на основании вопроса), ни к чему полезному не приведет.

← →
Плохиш (2004-02-11 11:02) [42]

Может вместо ProcessMessage, Refresh для формы вызывать?

← →
Тимохов (2004-02-11 11:09) [43]

> KSergey © (11.02.04 10:55) [41]

Большое спасибо за столь развернутый "опус".
Скопировал его себе - буду обдумывать.

В [40] Вы упомянули про фильтрацию сообщений. ЗдОрово было бы научиться это делать. Например, пропускать только те сообщения, которые отвечают за перерисовку. Все остальные (например, клики мышкой куда душе будет угодно) просто игнорировать - разрешать только кликать на кнопку "Прервать" на маленьком окошке. У меня есть ощущение, что этот путь вполне реален. Интересно пытался ли кто-нибудь такое сделать (и упешно реализовал:)))?

← →
Тимохов (2004-02-11 11:11) [44]

> Плохиш (11.02.04 11:02) [42]
> Может вместо ProcessMessage, Refresh для формы вызывать?

Вы имеет в виду для информационного окошка?
Как правильно заметил KSergey, хочется все-таки, чтобы другие формфы моего приложения, а не только информационное окошко, реагировали на сообщения о перерисовке...

← →
jack128 (2004-02-11 11:22) [45]

> хочется все-таки, чтобы другие формфы моего приложения,
>
Ну так перерисовывай все.
хинт: Screem.Forms[]

Но, повторюсь, имхо, не тем путем идешь..

← →
KSergey (2004-02-11 12:05) [46]

> [42] Плохиш (11.02.04 11:02)
> Может вместо ProcessMessage, Refresh для формы вызывать?

Первый вопрос: как часто это надо делать? Т.е. упираемся в ту же проблему "как часто вызывать ProcessMessages"
Но это бы все ничего, но есть другой огромный косяк: при вызове ProcessMessages обрабатываются только те сообщения, которые есть в очереди. В частности, если там есть WM_PAIT - требуемые окна перерисуются. Если ничего нет - выход произойдет довольно быстро.
Refresh же в любом случае заставит контрол принудительно перерисовываться, даже если этого и не требуется (пользователь никуда и не думал переключаться), что может занять продолжительное время.

> [43] Тимохов © (11.02.04 11:09)
> В [40] Вы упомянули про фильтрацию сообщений. ЗдОрово было
> бы научиться это делать. Например, пропускать только те
> сообщения, которые отвечают за перерисовку. Все остальные
> (например, клики мышкой куда душе будет угодно) просто игнорировать
> - разрешать только кликать на кнопку "Прервать" на маленьком
> окошке. У меня есть ощущение, что этот путь вполне реален.
> Интересно пытался ли кто-нибудь такое сделать (и упешно
> реализовал:)))?

Проблема как раз в том, чтобы определиться что пропускать, а что нет.
В общем случае, как я понимаю, надо приложить весьма серьезные усилия для изучения всех сообщений, кроме того необходимо четко понимать какое из них что делает и в каком порядке они должны идти. А сообщений этих - туева хуча, доложу я вам.
Однако в системе есть готовая ф-ция EnableWindow, которая и так делает все что надо (а что надо - только в MS знают точно ;), а на ее основе мы имеем счатье лицезреть готовую реализацию DisableTaskWindows/EnableTaskWindows. Так стоит ли изобретать велосипед, все элементы которого мы к тому же не знаем?

← →
Тимохов (2004-02-11 12:07) [47]

Вот с этим

> В общем случае, как я понимаю, надо приложить весьма серьезные
> усилия для изучения всех сообщений, кроме того необходимо
> четко понимать какое из них что делает и в каком порядке
> они должны идти. А сообщений этих - туева хуча, доложу я
> вам

и с этим

> (а что надо - только в MS знают точно ;

Побностью согласен - будем копать. :((((

← →
KSergey (2004-02-11 12:11) [48]

> [45] jack128 © (11.02.04 11:22)
> Но, повторюсь, имхо, не тем путем идешь..

А, к стати, каким надо? Или хотя бы какие есть еще варианты, кроме мною описанных?

← →
KSergey (2004-02-11 12:14) [49]

> [47] Тимохов © (11.02.04 12:07)
> Побностью согласен - будем копать. :((((

Копать куда? В сторону изучения всех сообщений?
Дохлое дело. Хотя бы так: что делать с пользовательскими сообщениями (начиная от WM_USER и далее)? Глушить? Пропускать? А что задумывалось разработчиком под ними? А ведь библиотека VCL этими сообщениями просто изобилует! Еще и их изучать? А зачем, если все уже сделано?

← →
Тимохов (2004-02-11 12:17) [50]

> Еще и их изучать? А зачем, если все уже сделано?

Копать в сторону решения проблемы - несколько ямок уже есть. Еще десяток будет - будем выбирать, которую копать дальше :))))

← →
Barbarian five (2004-02-11 14:02) [51]

Долгие операции надо засовывать исключительно в потоки. Сделать это совсем не сложно. А вот если использовать ProcessMessages, то можно вообще зависнуть в случае, если в этот момент будет запущен другой долгий цикл (после нажатия на кнопку, например), т.е. не выйти из него. Это все не есть гуд, и для параллельных операций (цикл и отображение на форме) специально придумали многозадачность. Так воспользуемся же ею!

Delphi + WinApi Найти похожие ветки