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

Question

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

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

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

Answer 1

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

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

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

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

• создание окна не в той теме

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

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

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

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