Я пишу библиотеку, которая включает в себя некоторые функции Media Foundation. Я хочу иметь возможность уведомить пользователя библиотеки посредством обратного вызова о том, когда веб-камера подключена / отключена от системы. MSDN описывает, как узнать, когда камера отключена, но он использует цикл сообщений, чтобы сообщить вам об этом. Я не очень хорошо знаю петли сообщений Windows, но то, что я прочитал в эта статья MSDN говорит мне, что у меня должно быть окно, чтобы иметь цикл сообщений, что неприемлемо для библиотеки.
Итак, у меня есть несколько вопросов:
Могу ли я создать цикл сообщений в новом потоке и получать уведомления, описанные в первой ссылке? (Я хочу, чтобы он был в новом потоке, чтобы он не блокировал поток пользователя библиотеки, тогда пользователь библиотеки вызывает setCameraChangeCallback(...)
, который запускает цикл сообщений внутри.) Если да, то какие функции для создания цикла сообщений я должен использовать?
Могу ли я сделать это без создания каких-либо окон? Это библиотека, поэтому было бы очень странно, если бы пользователь библиотеки setCameraChangeCallback(...)
и вдруг появилось окно. Опять же, объяснение того, как это сделать (имена функций, конкретные аргументы и т. Д.), Приветствуется.
Можно ли без проблем использовать мою библиотеку в приложении Windows? Это означает, что в приложении Windows, которое будет использовать мою библиотеку, вероятно, уже создано окно и запущен собственный цикл обработки сообщений. Будет ли мой цикл сообщений, работающий в отдельном потоке, мешать циклу сообщений пользователя библиотеки? Если так, как этого избежать?
Что-то мешает мне создать два или более потоков с циклами сообщений, каждый из которых зарегистрирован для получения уведомления о событии смены камеры?
В этой статье MSDN говорится, что у меня должно быть окно для цикла сообщений, что неприемлемо для библиотеки.
Не так. Создать окно только для сообщений, или даже просто скрытое окно. Позвольте этому окну получать уведомления и пересылать их.
Вы можете сделать это в специальной теме, если хотите, или нет. Какой бы поток ни выполнял код, который создает окно, он считается потоком-владельцем окна. Сообщения отправляются в эту ветку. Этот поток должен отправлять сообщения, чтобы окно получало их.
На первый взгляд, вы можете подумать, что будет проще создать окно в отдельном потоке и изолировать его от основного приложения. Это имеет свои преимущества, но цена заключается в том, что вам необходимо учитывать, что происходит, когда вы хотите переслать уведомления. Полученные вами сообщения будут поступать в вашу специальную ветку. Если вы перенаправляете события напрямую, то хост вашей библиотеки будет выполнять код асинхронно в вашем выделенном потоке. Это действительно то, что вы хотите?
Более распространенный подход заключается в том, что события запускаются в потоке узла, который первоначально запрашивал получение уведомлений. Это будет означать, что вашей библиотеке потребуется, чтобы приложение хоста отправляло сообщения.
Очевидно, у вас есть несколько вариантов, чтобы сделать здесь. Но суть в том, что вы не должны верить, что код библиотеки не должен создавать окна. Окна не должны быть видимыми, и действительно, окна только для сообщений разработаны специально для вашего сценария использования.