ATL problem
-
Hi! I get a ATL object by other object's method. like below STDMETHODIMP CBanana::GetApple(IApple** apple) { CComObject* p =NULL; CComObject::CreateInstance(&p); p->QueryInterface(apple); return S_OK; } But i dont know how to turn it back( from interface to real class). the code list below seems doesn't work. STDMETHODIMP CBanana::DoSomethingOnApple(IApple* apple) { CApple* p = dynamic_cast(apple); p->num = 3; } I think dynamic_cast can't be used in this situation. But i really don't know the proper way. Would you please lend me a hand? I have blocked in this problem for almost one week.
-
Hi! I get a ATL object by other object's method. like below STDMETHODIMP CBanana::GetApple(IApple** apple) { CComObject* p =NULL; CComObject::CreateInstance(&p); p->QueryInterface(apple); return S_OK; } But i dont know how to turn it back( from interface to real class). the code list below seems doesn't work. STDMETHODIMP CBanana::DoSomethingOnApple(IApple* apple) { CApple* p = dynamic_cast(apple); p->num = 3; } I think dynamic_cast can't be used in this situation. But i really don't know the proper way. Would you please lend me a hand? I have blocked in this problem for almost one week.
You don't have to convert it back. If you look at the definition of CComObject<> you'll see:
template
class CComObject : public Basewhich means that
CComObject<Base>inherits fromBase. EverythingBasehas to offer, so willCComObject<Base>. -- Serial killers don't kill their boyfriends. -
Hi! I get a ATL object by other object's method. like below STDMETHODIMP CBanana::GetApple(IApple** apple) { CComObject* p =NULL; CComObject::CreateInstance(&p); p->QueryInterface(apple); return S_OK; } But i dont know how to turn it back( from interface to real class). the code list below seems doesn't work. STDMETHODIMP CBanana::DoSomethingOnApple(IApple* apple) { CApple* p = dynamic_cast(apple); p->num = 3; } I think dynamic_cast can't be used in this situation. But i really don't know the proper way. Would you please lend me a hand? I have blocked in this problem for almost one week.
novachen wrote: But i dont know how to turn it back( from interface to real class Rule of thumb: You must not, because your apple might sit on a server in Siberia. Long answer: Unless you know 100% that the class implementing IApple was created on the same machine, in the same process (a few registry entries could easily break that). One of the fundamentals of COM is that you can never assume anything about the Implementing class, only abotu the interfaces. The bad thing is, it works most of the time, for inproc servers, so people try it.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen -
novachen wrote: But i dont know how to turn it back( from interface to real class Rule of thumb: You must not, because your apple might sit on a server in Siberia. Long answer: Unless you know 100% that the class implementing IApple was created on the same machine, in the same process (a few registry entries could easily break that). One of the fundamentals of COM is that you can never assume anything about the Implementing class, only abotu the interfaces. The bad thing is, it works most of the time, for inproc servers, so people try it.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygenThanks! But in fact, I try to hide a complex structure inside COM interface. On the interface of COM, Apple is a very simple object, but in the eyes of the other objects in the same COM dll, Apple has more content than the interface. So i hope IApple can turn back into CApple, that i can access the hid part. I can't confirm the objects sit with client at same computer, but i can confirm those objects access each other on the same server. How can i achieve this design?
-
You don't have to convert it back. If you look at the definition of CComObject<> you'll see:
template
class CComObject : public Basewhich means that
CComObject<Base>inherits fromBase. EverythingBasehas to offer, so willCComObject<Base>. -- Serial killers don't kill their boyfriends. -
Why do the conversion to IApple to begin with? It is possible, but very unsafe, see peterchens answer down below. A rule of thumb is to convert to IApple's just before they leave a method defined in a COM interface. -- You know me. I sure know you.. Everyone of you!
-
Thanks! But in fact, I try to hide a complex structure inside COM interface. On the interface of COM, Apple is a very simple object, but in the eyes of the other objects in the same COM dll, Apple has more content than the interface. So i hope IApple can turn back into CApple, that i can access the hid part. I can't confirm the objects sit with client at same computer, but i can confirm those objects access each other on the same server. How can i achieve this design?
You cam 1. Make Apple only creatable by Banana 2. Tag each Apple instance with a GUID, that can be queried through the IApple interface 3. Keep a map<GUID, CApple *> to retrieve the CApple * belonging to an IApple * 4. Reject each IApple you get that you don't know. I have a slightly simpler case, that uses a slightly simpler implementation: Noone passes an IApple back to me (I just hand it out), and the apple doesn't have any state that can't be dereived from Banana. So I let the Banana implement the methods of Apple and make the IApple implementation forward the calls to it's Banana. Some care with avoiding circular ref's is all to take care of.
"Der Geist des Kriegers ist erwacht / Ich hab die Macht" StS
sighist | Agile Programming | doxygen