Delphi - цикл сообщений для формы, созданной в фильтре DirectShow, останавливается - PullRequest
0 голосов
/ 03 апреля 2010

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

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

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

1 Ответ

1 голос
/ 03 апреля 2010

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

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

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

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

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

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

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

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

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

...