Question

I have a DirectShow filter created with Delphi Pro 6 and the DSPACK direct show library. I’m running under windows XP. I’ve tried creating the form dynamically when the container class for the DirectFilter has its constructor called, passing NIL into the constructor as the AOwner parameter (TMyForm.Create(nil) and then calling the Form’s Show() method. The form does show but then appears to stop receiving windows messages because it never repaints and does not respond to input. As a test I then tried creating my own WndProc() and overriding the Form’s WndProc(). My WndProc() did get called once but never again.

I’m guessing it’s because I’m a DLL and the context that I am running in is not “friendly” to the window message handler for the form; perhaps something to do with the thread that calls it or whatever. If someone could give me a tip on how to solve this or what the proper way to create a persistent window is from the context of a DirectShow filter I’d appreciate it. Note, as I said the window needs to be persistent so I can’t create it as a Filter property page.

Thanks,
Robert

Answer 1

I can’t help you with the DirectShow filter specifics, but I feel that some general information about windows and message handling might help.

Windows have thread affinity, which means that all messages for a window will be handled in the context of the thread that created it. That means that this thread needs to have the standard message processing loop, the low level equivalent of Application.ProcessMessages(). Both messages from the same and from other threads will be queued in the message queue of the creating thread, and the message loop will get them, (optionally) translate them, and dispatch them to the window handler of the target window.

What you are describing could be caused by either

• not having a message processing queue in the thread that creates the window, or

• creating the window in the wrong thread

(Note that these are essentially the same, but stated like this it becomes apparent that there may be different problems that cause this, which need to be fixed in different ways – either the window needs to be created in a different thread, or a processing loop needs to be created in the thread.)

You need to find out which of the two causes your window not to process messages. You don’t necessarily need to override WndProc(), message handling methods for distinct messages will work (or not work) the same. That your WndProc() was called once doesn’t really tell you much, because under some circumstances messages sent from the same thread will be handled without the message loop, by calling the window proc directly.

Since your filter resides in a DLL I don’t think that creating your own message loop would be the right thing. This works for a modal dialog, which will be created, the message loop will run until the dialog is closed, and then the message loop will terminate and the DLL function will return. It will not work for a DLL exported function that will be called and needs to return all while the message loop is still running. I assume the framework that creates and calls those filters will handle the message loop as well. However, that is a gut feeling, not knowing about DirectShow filters this may well be wrong.

What might help you to debug this is a tool like Spy++ from Visual Studio, with which you can show information about windows, log messages sent to them or to all windows in the same process or thread, show window hierarchies and do a lot of other interesting things. If you don’t have that, there are a lot of clones (some freeware) on the net, which Google should turn up. Trying to show the messages sent to all windows of the same thread or process should tell you whether a message loop is running. You should also be able to get more information by running SysInternals Process Explorer or similar tools.