Delphi - цикл сообщений для формы, созданной в фильтре DirectShow, не работает

Question

У меня есть фильтр DirectShow, созданный с помощью Delphi Pro 6 и библиотеки прямого просмотра DSPACK. Я работаю под Windows XP. Я попытался создать форму динамически, когда класс контейнера для DirectFilter вызвал свой конструктор, передав NIL в конструктор в качестве параметра AOwner (TMyForm.Create (nil), а затем вызвав метод Form's Show(). Форма показывает но затем перестает получать сообщения Windows, потому что он никогда не перерисовывается и не реагирует на ввод. В качестве теста я попытался создать свой собственный WndProc() и переопределить WndProc() формы. My WndProc() получил вызов один раз, но больше никогда .

Я предполагаю, что это потому, что я - DLL, и контекст, который я запускаю, не является «дружественным» к обработчику оконных сообщений для формы, возможно, что-то связанное с потоком, который его называет Если кто-то может дать мне подсказку о том, как решить эту проблему или как правильно создать постоянное окно, это контекст фильтра DirectShow, я бы его оценил. Я сказал, что окно должно быть постоянным, поэтому я не могу создать его как страницу свойств фильтра.

Спасибо, Роберт

Answer 1

Я не могу помочь вам с особенностями фильтра DirectShow, но я чувствую, что некоторые общие сведения об окнах и обработке сообщений могут помочь.

В Windows есть сходство с потоком, что означает, что все сообщения для окна будут обрабатываться в контексте потока, который его создал. Это означает, что этот поток должен иметь стандартный цикл обработки сообщений, эквивалент низкого уровня Application.ProcessMessages(). Оба сообщения из одного и того же и из других потоков будут помещены в очередь в очереди сообщений создаваемого потока, и цикл сообщения получит их (необязательно) их перевести и отправит их обработчику окна целевого окна.

То, что вы описываете может быть вызвано либо

• не имеющими очереди обработки сообщений в потоке, который создает окно, или

• создания окна в неправильном потоке

(Обратите внимание, что это по существу то же самое, но, как указано, это становится очевидным, что могут возникнуть различные проблемы, которые вызывают это, d для исправления по-разному - либо окно должно быть создано в другом потоке, либо в потоке необходимо создать цикл обработки).

Вам нужно выяснить, какая из двух причин вызывает ваше окно не для обработки сообщений. Вам необязательно переопределять WndProc(), методы обработки сообщений для отдельных сообщений будут работать (или не работать) одинаково. То, что ваш WndProc() был вызван однажды, на самом деле вам не очень-то говорит, потому что в некоторых случаях сообщения, отправленные из одного потока, будут обрабатываться без цикла сообщений, вызвав непосредственно окно proc.

Поскольку ваш фильтр находится в DLL, я не думаю, что создание вашего собственного цикла сообщений было бы правильным. Это работает для модального диалога, который будет создан, цикл сообщения будет работать до тех пор, пока диалог не будет закрыт, а затем цикл сообщения завершится и функция DLL вернется. Он не будет работать для экспортированной DLL-функции, которая будет вызываться и должна возвращать все, пока цикл сообщений все еще запущен. Я предполагаю, что структура, которая создает и вызывает эти фильтры, будет обрабатывать цикл сообщений. Однако это ощущение кишки, не зная о фильтрах DirectShow, это может быть неправильно.

Что может помочь вам отладить этот инструмент, такой как Spy ++ из Visual Studio, с помощью которого вы можете отображать информацию о окнах, сообщениях журналов, отправленных им или ко всем окнам одного и того же процесса или потока, показывать иерархии окон и делать много других интересных вещей. Если у вас этого нет, в сети много клонов (некоторые бесплатные), которые Google должен появиться. Попытка показать сообщения, отправленные во все окна одного потока или процесса, должна указать, работает ли цикл сообщений. Вы также можете получить дополнительную информацию, запустив SysInternals Process Explorer или аналогичные инструменты.