I can't do this, can I? (COM)

SunnyD

Belgian Waffler
Jan 2, 2001
32,675
146
106
www.neftastic.com
Tell me what is and isn't possible here please:

COM object "A" contains a property 'array' of interface pointers to some number of COM objects "B", which the objects are 'created' by object "A" for consumption elsewhere.

In order to set object(s) "B"s' properties, I have to do it through an interface correct? There's no way to use internal methods to set "B"s' properties? Reason is, I really want all of "B"s' properties to be read-only to the outside world, but only allowing "A" (who is responsible for creating every instance of "B") to be able to set them.

Let me know if this doesn't make sense.
 

SunnyD

Belgian Waffler
Jan 2, 2001
32,675
146
106
www.neftastic.com
Originally posted by: nickbits
You can cast your B pointers back to B class and use the B class methods.

I didn't think it was possible/legal to cast the interface pointers to the actual coclass. Though I suppose in a way it makes sense, since otherwise COM wouldn't have a clue how to get to the implementation for an interface.

I assume I would use dynamic_cast<CoClass*>Interface* for that?
 

nickbits

Diamond Member
Mar 10, 2008
4,122
1
81
Originally posted by: SunnyD
Originally posted by: nickbits
You can cast your B pointers back to B class and use the B class methods.

I didn't think it was possible/legal to cast the interface pointers to the actual coclass. Though I suppose in a way it makes sense, since otherwise COM wouldn't have a clue how to get to the implementation for an interface.

I assume I would use dynamic_cast<CoClass*>Interface* for that?

Yeah that should work. The "purest COM" solution would be to make a private setter interface but the cast works fine.

I normally use ATL for COM and you don't CoCreateInstance on your internal objects normally so I always have a pointer to be base class.
 

SunnyD

Belgian Waffler
Jan 2, 2001
32,675
146
106
www.neftastic.com
Originally posted by: nickbits
Originally posted by: SunnyD
Originally posted by: nickbits
You can cast your B pointers back to B class and use the B class methods.

I didn't think it was possible/legal to cast the interface pointers to the actual coclass. Though I suppose in a way it makes sense, since otherwise COM wouldn't have a clue how to get to the implementation for an interface.

I assume I would use dynamic_cast<CoClass*>Interface* for that?

Yeah that should work. The "purest COM" solution would be to make a private setter interface but the cast works fine.

I normally use ATL for COM and you don't CoCreateInstance on your internal objects normally so I always have a pointer to be base class.

I thought the whole idea of COM interfaces was so that they were discoverable. How do you make a "private" interface as such?

I'm using ATL for this project - so I'm not using CoCreateInstance for the internal objects? How am I supposed to provide these objects (or their interfaces) to the outside world then? I simply want to make sure their properties are set internally by the "parent" object, but they have to be consumable by an external entity.
 

nickbits

Diamond Member
Mar 10, 2008
4,122
1
81
Originally posted by: SunnyD
Originally posted by: nickbits
Originally posted by: SunnyD
Originally posted by: nickbits
You can cast your B pointers back to B class and use the B class methods.

I didn't think it was possible/legal to cast the interface pointers to the actual coclass. Though I suppose in a way it makes sense, since otherwise COM wouldn't have a clue how to get to the implementation for an interface.

I assume I would use dynamic_cast<CoClass*>Interface* for that?

Yeah that should work. The "purest COM" solution would be to make a private setter interface but the cast works fine.

I normally use ATL for COM and you don't CoCreateInstance on your internal objects normally so I always have a pointer to be base class.

I thought the whole idea of COM interfaces was so that they were discoverable. How do you make a "private" interface as such?

I'm using ATL for this project - so I'm not using CoCreateInstance for the internal objects? How am I supposed to provide these objects (or their interfaces) to the outside world then? I simply want to make sure their properties are set internally by the "parent" object, but they have to be consumable by an external entity.

You make it private just by not giving out the specs/GUID to the interface--Microsoft does that all the time. Technically they would still be in your QueryInterface function but w/o the specs they are essentially hidden.

For internal objects I usually just do something like (from MSDN):

// Create a local instance of COM object CMyCircle.
double x;
CComObject<CMyCircle>* pCircle;
HRESULT hRes = CComObject<CMyCircle>::CreateInstance(&pCircle);
ATLASSERT(SUCCEEDED(hRes));

// Increment reference count immediately
pCircle->AddRef();

// Access method of COM object
hRes = pCircle->get_XCenter(&x);

// Decrement reference count when done
pCircle->Release();
pCircle = NULL;


You can call the internal methods from pCircle and QI for the public interfaces.

 

SunnyD

Belgian Waffler
Jan 2, 2001
32,675
146
106
www.neftastic.com
Ah, alright, I was thinking about it after posting that and figured I'd have to call AddRef() and Release() manually.

The "private" COM won't help. This is all security related, so I have to keep things as tight as possible. As long as I can cast it down and access the implementation class, that should suffice. It will be ugly, but it will do. Just to be clear, my point here is that the interface for said object only exposes get, but I should still be able to access the coclass methods through a cast?