Есть ли смысл маркировать интерфейс, полученный из IUnknown, как двойной в IDL?
-
06-07-2019 - |
Вопрос
Просматривая наш код, я нашел любопытное определение в одном из файлов .idl:
[
object,
uuid(uuidhere),
dual,
nonextensible,
oleautomation,
hidden
]
interface IOurInterface : IUnknown {
//methods here
};
Как интерфейс, полученный непосредственно из IUnknown
, может быть двойным интерфейсом? Что-нибудь сломается, если я удалю атрибут dual
?
Решение
В этот ответ на другой вопрос, касающийся маршалинга пользователь voyce указывает на эта статья , в которой в основном говорится следующее:
Когда какой-либо интерфейс (производный от IDispatch или нет) помечается как dual
или oleautomation
(или оба), он обрабатывается специально, когда RegisterTypeLib () Код> вызывается (что обычно делается DllRegisterServer). Для каждого такого интерфейса создается ключ HKCR \ Interface {InterfaceId}, в котором класс {00020424-0000-0000-C0000-000000000046} упоминается как прокси / заглушка. Этот идентификатор класса соответствует маршаллеру typelib, также известному как маршаллер oleautomation.
Другие советы
Я не вижу причины, по которой это сработает, учитывая документы здесь: http://msdn.microsoft.com/en-us /library/aa366807(VS.85).aspx р>
Интерфейсы, идентифицированные двойным атрибут должен быть совместим с Автоматизация и быть производным от IDispatch. Этот атрибут не разрешено на интерфейсах.
Возможно, атрибут [dual]
неявно добавляет IDispatch
в интерфейс.
Что вы можете сделать, это проверить код, реализующий интерфейс (при условии, что это ATL), если он наследуется от IDispatchImpl
. Если это так, он фактически отвечает на QI для IDispatch
и может использоваться как таковой.
Другой альтернативой является создание экземпляра объекта, реализующего IOurInterface
, и его QI для IDispatch
- если это удастся, вы, вероятно, не сможете его удалить.
На самом деле, если подумать, может быть, [dual]
технически не требует, чтобы вы наследовали от IDispatch
, пока вы реализуете как пользовательский интерфейс, так и < код> IDispatch код>