¿Tiene sentido marcar una interfaz derivada de IUnknown como dual en IDL?
-
06-07-2019 - |
Pregunta
Al revisar nuestro código, he encontrado una definición curiosa en uno de los archivos .idl:
[
object,
uuid(uuidhere),
dual,
nonextensible,
oleautomation,
hidden
]
interface IOurInterface : IUnknown {
//methods here
};
¿Cómo puede una interfaz derivada directamente de IUnknown
posiblemente ser una interfaz dual? ¿Se romperá algo si elimino el atributo dual
?
Solución
En esta respuesta a otra pregunta relacionada con el cálculo de referencias user voyce apunta a este artículo que básicamente establece lo siguiente:
Cuando cualquier interfaz (derivada de IDispatch o no) se marca como dual
o oleautomation
(o ambas) se trata especialmente cuando RegisterTypeLib () (que normalmente es realizado por DllRegisterServer). Para cada interfaz de este tipo, se crea una clave HKCR \ Interface {InterfaceId} bajo la cual {00020424-0000-0000-C0000-000000000046} clase se hace referencia como proxy / stub. Este identificador de clase corresponde a typelib marshaller, también conocido como oleautomation marshaller.
Otros consejos
No puedo ver una razón por la que eso funcionaría, dados los documentos aquí: http://msdn.microsoft.com/en-us /library/aa366807(VS.85).aspx
Interfaces identificadas por el dual El atributo debe ser compatible con Automatización y derivarse de IDispatch. Este atributo no es permitido en dispinterfaces.
Podría ser que el atributo [dual]
implícitamente agregue IDispatch
a la interfaz.
Lo que podría hacer es verificar el código que implementa la interfaz (suponiendo que sea ATL) si deriva de IDispatchImpl
. Si es así, en realidad responde a QI para IDispatch
y podría usarse como tal.
Otra alternativa es crear una instancia de un objeto que implemente IOurInterface
y QI para IDispatch
: si tiene éxito, probablemente no pueda eliminarlo.
En realidad, ahora que lo pienso, tal vez [dual]
no requiere técnicamente que derive de IDispatch
siempre que implemente tanto su interfaz personalizada como < code> IDispatch ?