How to interface a COM class in a non-COM DLL
-
Hi folks! ;) I need to create a DCOM Server to manage multiple objects (hardware driver wrappers). I Created DCOM Server with object classes and methods declaration, but I wanted to envelope every object in a separate DLL, to be modular. (just to make things easier if I wanna change a board, i.e.) Now, I created a Win32 DLL (I do not need COM support, while I'm just implementing functions) but I need to get by parameter the effective class of my COM object. I tried that by including the object H file with class declaration, but it tells me that ATL_NO_VTABLE cannot be understood. What can I do? Did I reason well? Or I need a COM DLL anyway? Thanks a lot for now, Morenz
-
Hi folks! ;) I need to create a DCOM Server to manage multiple objects (hardware driver wrappers). I Created DCOM Server with object classes and methods declaration, but I wanted to envelope every object in a separate DLL, to be modular. (just to make things easier if I wanna change a board, i.e.) Now, I created a Win32 DLL (I do not need COM support, while I'm just implementing functions) but I need to get by parameter the effective class of my COM object. I tried that by including the object H file with class declaration, but it tells me that ATL_NO_VTABLE cannot be understood. What can I do? Did I reason well? Or I need a COM DLL anyway? Thanks a lot for now, Morenz
Hi, I'm not sure what are you trying to achieve. I assume, that you have some DCOM object, exposing a set of functions, these being implemented in different .dlls, that can be dynamically loaded from your object. Problem is, that one of the parameters to these functions implemented in .dlls should be a pointer to the DCOM object that calls them. Is that right? I think you need to include the ATL headers into your dlls as well, to have defined the ATL macro
ATL_NO_VTABLE. This will not change your .dlls to COM dlls (they will not require the registration) There's also another problem with the ALT objects. There's an interesting twist, because ofIUnknownimplementation. To keep it short, simply your ATL object is not really the object being constructed. If I assume your object name isCMyObjectthen the object constructed is in factCComObject<CMyObject>. So to stay on the safe side, your parameter should not be onlyCMyClass&, butCComObject<CMyClass>&(or pointer if you prefer) Anyway, safest way would be to export some sort of interface from the DCOM object, that these dlls will use to communicate. Then you can take the declaration of the interface from the header file generated by MIDL and use it in the .dlls. (filename is usuallyprojectname.h) Hope this helps -
Hi, I'm not sure what are you trying to achieve. I assume, that you have some DCOM object, exposing a set of functions, these being implemented in different .dlls, that can be dynamically loaded from your object. Problem is, that one of the parameters to these functions implemented in .dlls should be a pointer to the DCOM object that calls them. Is that right? I think you need to include the ATL headers into your dlls as well, to have defined the ATL macro
ATL_NO_VTABLE. This will not change your .dlls to COM dlls (they will not require the registration) There's also another problem with the ALT objects. There's an interesting twist, because ofIUnknownimplementation. To keep it short, simply your ATL object is not really the object being constructed. If I assume your object name isCMyObjectthen the object constructed is in factCComObject<CMyObject>. So to stay on the safe side, your parameter should not be onlyCMyClass&, butCComObject<CMyClass>&(or pointer if you prefer) Anyway, safest way would be to export some sort of interface from the DCOM object, that these dlls will use to communicate. Then you can take the declaration of the interface from the header file generated by MIDL and use it in the .dlls. (filename is usuallyprojectname.h) Hope this helpsFirst of all thanx a lot, then... it's right what you say (about project architecure) but if I try to only #import my MIDL result (thats .TLB, not .h, I think) in my DLL, I have the error on ATL_NO_VTABLE. Do I have to #import all .idl files in my DLL? Or creating my CComObject& can work well? Thanx a lot again, I'm neither a COM nor a DLL expert (my last COM written was about in 1998... my last DLL in 1997...):laugh: Best regards, Morenz
-
First of all thanx a lot, then... it's right what you say (about project architecure) but if I try to only #import my MIDL result (thats .TLB, not .h, I think) in my DLL, I have the error on ATL_NO_VTABLE. Do I have to #import all .idl files in my DLL? Or creating my CComObject& can work well? Thanx a lot again, I'm neither a COM nor a DLL expert (my last COM written was about in 1998... my last DLL in 1997...):laugh: Best regards, Morenz
hm, as I could understand the
ATL_NO_VTABLEproblem, when you're including theobject.hfile, the code generated with#importnever contain the ATL macros. You probably forgot to remove theobject.hinclude. I always used#import "blahblah.tlb" no_namespace named_guidsfor including COM objects to my projects. Problem is, that this doesn't import the object as-is from the C++ point of view. It defines all interfaces the object is derived from and all Guids required for the object - Guids of interfaces and of the object itself. If you look into your debug (or release) directory, you'll seeobject.tlhandobject.tli(optional), that contains code generated by the#import. Well, when you have the interfaces imported, you can use one of them as a controlling interface. General interface isIUnknown. From this you canQueryInterfaceto get any other interface exported by the object. TheCComObjectthing is when you decide not to import interfaces, but the C++ object definition. The method I would choose depends on what you want to achieve, but generally I'd prefer to a) create a special interface for controlling the DCOM object, passed to the .dlls b) create a third c++ object, that is included in the DCOM as well as in the .dlls. It's purpose is only for exchanging the information - the DCOM object creates one instance and passes it to all calls to the .dlls. Or even considering the implementation to be in the C++ object and only calls from outside will be proxied through the DCOM object. Then the DCOM object will be only very thin wrapper - generally only thing it will does will be to create the third object (or derive from) and then simply proxy all calls from DCOM to the C++ object. I hope the explanation is clear, here's 7:00 morning ;-) The a) and b) are more or less equal, the a) is more COMish, while the b) is more C++ish. -
hm, as I could understand the
ATL_NO_VTABLEproblem, when you're including theobject.hfile, the code generated with#importnever contain the ATL macros. You probably forgot to remove theobject.hinclude. I always used#import "blahblah.tlb" no_namespace named_guidsfor including COM objects to my projects. Problem is, that this doesn't import the object as-is from the C++ point of view. It defines all interfaces the object is derived from and all Guids required for the object - Guids of interfaces and of the object itself. If you look into your debug (or release) directory, you'll seeobject.tlhandobject.tli(optional), that contains code generated by the#import. Well, when you have the interfaces imported, you can use one of them as a controlling interface. General interface isIUnknown. From this you canQueryInterfaceto get any other interface exported by the object. TheCComObjectthing is when you decide not to import interfaces, but the C++ object definition. The method I would choose depends on what you want to achieve, but generally I'd prefer to a) create a special interface for controlling the DCOM object, passed to the .dlls b) create a third c++ object, that is included in the DCOM as well as in the .dlls. It's purpose is only for exchanging the information - the DCOM object creates one instance and passes it to all calls to the .dlls. Or even considering the implementation to be in the C++ object and only calls from outside will be proxied through the DCOM object. Then the DCOM object will be only very thin wrapper - generally only thing it will does will be to create the third object (or derive from) and then simply proxy all calls from DCOM to the C++ object. I hope the explanation is clear, here's 7:00 morning ;-) The a) and b) are more or less equal, the a) is more COMish, while the b) is more C++ish.