Bonjour all, I''ve posted a question before about COM, and I had another one for you fun-loving COM gurus.. So leaving off from my last posting, I had designed a small virtual class called IRenderer which I have instantiated in 2 DLL''s by OGLRenderer and D3DRenderer classes which inherit the IRenderer interface... NOW I was looking to hide the factory that creates the IRenderer object (which led me to look into COM in the first place)..HOWEVER, I want to know if it''s possible (and how) to set it up so that the factory creates either component without loading BOTH up... In another way of looking at it...(from my rudimentary COM understanding)..you hide your component factory class inside the COM dll. Fine. Then when you instantiate the component, the COM dll does your instantiation work. Got it. What I''d LIKE to do, is when my IRenderer COM component gets instantiated, it loads up EITHER the D3DRenderer implementation OR the OGLRenderer implementation...but not both... Am I making sense?? Basically if I put the OGLRenderer and D3DRenderer in the same COM component DLL then ALL the code gets loaded when an IRenderer interface is instantiated correct?? Can''t I split this up a bit?? thanks for any help for my muddled thoughts here.. Wazoo

Well, if you take a utilitarian approach, you can do it very easily. Have two separate DLLS, each with a CreateRenderComponent() function. Load whichever one the user specifies.

hmmm so in the end I''m just creating 3 dll''s??

1. The IRenderer COM component which contains the factory class responsible for creating either the OGLRenderer or the D3DRenderer implementation, which (once it figures out which one to create) uses LoadLibrary to load the appropriate DLL..

2. The OGLRenderer COM component
3. The D3DRenderer COM component

Wow...seems like a lot of DLL''s...(thanks for suggestions though...maybe it IS the only way)..

Wazoo

Thanks for the suggestions! Yeah I guess I forgot that factories were on a per component case not a per interface one...

hmmmm this has given me quite a bit to think about. I'll go through this stuff over the weekend and see what I can come up with...

If anyone has any other suggestions, please don't hesitate to do so...

thanks!

Erik

btw. I actually have done what AP suggested above...I was just hoping to leave that in a COM-component, rather than have the user of my library have to create a factory class instance..

something like..

  CoCreateInstance(...., IID_IRenderer, OPENGL, &pRenderer, NULL);  

in ONE line!! Rather than have the user do:

  GraphicsFactory *gfx = new GraphicsFactory();pRenderer = gfx->createRenderer(OPENGL);//use the render then in destruction code..gfx->destroyRenderer(&pRenderer);delete gfx;pRenderer = NULL;  

I don't know...to me the COM way might be a lot cleaner...


Edited by - wazoo69 on June 15, 2001 6:02:34 PM

If you're making COM Objects, use the ATL!!!
You'll never make a COM object without it again
You need to make sure to twiddle all the default settings to make a base object (the defaults are setup for an ActiveX control, go figure)

The ATL will provide all the repetive interface implementations for you (MI rocks).


Every coclass needs a classfactory for COMpliance

In order to do want you want, I'd suggest creating a facade class. Something like CGraphicsEngine; inside this class you put all the code that decides which rendering sub-system to use and it instances the appro. coclass puts it's IRender interface to work.

In order to prevent the code from being loaded I think it has to be in a different dll - in a different COM library.

Soo it'll require no less than two dll's, if not three.

Edited by - Magmai Kai Holmlor on June 15, 2001 10:03:20 PM

I not really agree with you.
ATL mean MIDL (i not sure but i guess atl need MIDL) no?
no void*.
char* converted to unsigned char* but not really, just to make a bug.
It a great tool for buissness apps. But for game i''m not sure. Old COM is better an so you see what it append.

Why English rules?? C pas très malin tout ça!

I''m pretty sure I was able to use whatever types I wanted with ATL. In any case, I''ve always programmed COM with either ATL or MFC. The complexity without either of those two libraries would probably overwhelm me.