Поэтому я начал писать программу на C, которая потребовала бы много причудливого рисунка, но я строго в Windows, поэтому решил использовать Direct2D.
На данный момент я создаю настраиваемый элемент управления в DLL, который программа потребляет и использует как любой другой элемент управления Win32. Пользовательский элемент управления настраивает контекст D2D внутри своего окна и втягивает в него все, что ему нужно, и это отлично работает.
Я понял, что это сделало бы очень полезную DLL в будущих проектах по настройке и разрыву Direct2D с помощью традиционного интерфейса управления, поэтому я заставил элемент управления отправить уведомление родительскому окну, когда пришло время рисовать, вместо того, чтобы называть его собственный внутренний код чертежа (в основном, как нарисованные владельцем элементы управления). Он вызывает BeginDraw, затем отправляет уведомление родителям с пользовательским NMHDR, который содержит указатель на ID2D1DCRenderTarget, а затем вызывает EndDraw. В моем главном окне я создаю элемент управления, затем отвечаю на уведомление, затем вызываю методы для рисования материала, а затем возвращаю.
Проблема в том, что когда EndDraw вызывается в DLL, я получаю сообщение об ошибке "Объект не был в правильном состоянии для обработки метода". Это заставляет меня думать, что пересечение границ DLL должно затухать с операцией. Всегда ли DLL запускаются в том же потоке, что и приложенный процесс? Есть ли еще какая-то странность в пересечении границ DLL, особенно в отношении Direct2D?
Благодарю.
Спасибо за ответы! Просто понял, что это связано с привязкой DC к RenderTarget, так что обвиняйте меня.
Это заставляет меня думать, что пересечение границ DLL должно затухать с операцией. Всегда ли DLL запускаются в том же потоке, что и приложенный процесс? Есть ли еще какая-то странность в пересечении границ DLL, особенно в отношении Direct2D?
Нет, вызов функции, которая живет в другой DLL, ничем не отличается от вызова функции в том же модуле, что и вызывающий. Помните, что стандартные элементы управления Windows всегда существуют в разных модулях со своих хостов, например user32.dll, comctl32.dll и т.д.
Проблема в вашем коде не связана с тем, что она находится в другом модуле.