Use Windows message loop to receive an event in a library I'm writing

Question

I'm writing a library that wraps some of Media Foundation functionality. I want to be able to notify a library user through a callback of when a webcam is connected/disconnected to/from the system. MSDN describes how to know when a camera is disconencted , but it uses message loop to let you know of that. I don't know Windows message loops too well, but what I have read in this MSDN article tells me that I must have a window in order to have a message loop, which is unacceptable for a library.

So, I have several questions:

1. Can I create a message loop in a new thread and receive those notification messages described by the first link? (I want it to be in a new thread so that it doesn't block the library user's thread then the library user calls setCameraChangeCallback(...) , which starts the message loop inside.) If so, which functions for creating message loop should I use?

2. Can I do that without creating any windows? It's a library, so it would be very odd if a library user called setCameraChangeCallback(...) and a window suddenly appeared. Again, an explanation of how to do that (function names, specific arguments to use, etc.) is very welcome.

3. Can my library be used without issues in a Windows application? Meaning that a Windows application that would be using my library is likely to already have a window created and its own message loop running. Would my message loop running in the separate thread interfere with library user's message loop? If so, how to avoid that?

4. Does anything stop me from creating two or more threads with message loops, each registered to get notified for the camera change event?

Answer 1

This MSDN article tells me that I must have a window in order to have a message loop, which is unacceptable for a library.

Not so. Create a message only window , or even just a hidden window. Let that window receive the notification messages and then forward them.

You can choose to do this inside a dedicated thread if you wish, or not. Whichever thread executed the code that creates the window is deemed to be the owning thread of the window. Messages are sent to that thread. That thread must dispatch messages in order for the window to receive them.

On the face of it, you may think that it will just be cleaner to create the window in a dedicated thread and so isolate it from the host application. That has benefits, but the cost is that you need to consider what happens when you wish to forward notification events. The messages that you receive will arrive in your dedicated thread. If you forward events directly then your library's host will end up executing code asynchronously in your dedicated thread. Is that really what you want?

A more common approach would see the events being fired in the host thread that originally requested to receive notifications. That would mean your library would have to require that the host application dispatched messages.

Clearly you have some choices to make here. But the bottom line is that you should not believe that library code must not create windows. Windows need not be visible and indeed message only windows are designed specifically for your usage scenario.