> I have a COM service that defines two COM objects.  The first
> (ProductDataAccess) creates instances of the second
> (ProductDataObject) and then populates them from a database.  To
> perform the data population the ProductDataObject needs to be passed
> into the constructor of another, non-COM class.  Here is the function:

> STDMETHODIMP CCOMProductDataAccess::getData(/*[in]*/BSTR identifier,
> /*[out,retval]*/ ICOMProductDataObject** result)
> {
>   //  create the COM object that we want to populate
>   CComPtr<ICOMProductDataObject> myCOMobj;
>   HRESULT hr = myCOMobj.CreateInstance(CLSID_COMProductDataObject);
>   if (FAILED(hr)) return hr;

>   //  now create the non-COM object that will perform the population
>   GetStockInfo gsi(myCOMobj);

>   //  call function on GetStockInfo class that will populate the COM
> object
>   gsi->getData();

>   //  send the newly populated object back to the client
>   (*result) = myCOMobj;

>    return S_OK;
> }

> The prototype of the GetStockInfo class's constructor is:

> class GetStockInfo
> {
> public:
>   GetStockInfo(CCOMProductDataObject* obj)
>   {
>     // load stuff from database
>     obj->populate(param1, param2, ..., paramN);
>   }
> };

> However, I don't seem to be able to get the GetStockInfo class to
> recognise what the CCOMProductDataObject is.  Am I wrong in thinking
> that, in this case, I can just pass the CCOMProductDataObject to the
> function and that I don't need to worry about the interface pointer
> and stuff like that?  This is all taking place within the same COM
> call, so I'm sure it should be possible.

> Any help greatly appreciated!  If you could copy any responses to my
> e-mail address as well as to the newsgroup then that would be most
> helpful.

> thanks guys
> mike

> > I have a COM service that defines two COM objects.  The first
> > (ProductDataAccess) creates instances of the second
> > (ProductDataObject) and then populates them from a database.  To
> > perform the data population the ProductDataObject needs to be passed
> > into the constructor of another, non-COM class.  Here is the function:

> > STDMETHODIMP CCOMProductDataAccess::getData(/*[in]*/BSTR identifier,
> > /*[out,retval]*/ ICOMProductDataObject** result)
> > {
> >   //  create the COM object that we want to populate
> >   CComPtr<ICOMProductDataObject> myCOMobj;
> >   HRESULT hr = myCOMobj.CreateInstance(CLSID_COMProductDataObject);
> >   if (FAILED(hr)) return hr;

> >   //  now create the non-COM object that will perform the population
> >   GetStockInfo gsi(myCOMobj);

> >   //  call function on GetStockInfo class that will populate the COM
> > object
> >   gsi->getData();

> >   //  send the newly populated object back to the client
> >   (*result) = myCOMobj;

> >    return S_OK;
> > }

> > The prototype of the GetStockInfo class's constructor is:

> > class GetStockInfo
> > {
> > public:
> >   GetStockInfo(CCOMProductDataObject* obj)
> >   {
> >     // load stuff from database
> >     obj->populate(param1, param2, ..., paramN);
> >   }
> > };

> > However, I don't seem to be able to get the GetStockInfo class to
> > recognise what the CCOMProductDataObject is.  Am I wrong in thinking
> > that, in this case, I can just pass the CCOMProductDataObject to the
> > function and that I don't need to worry about the interface pointer
> > and stuff like that?  This is all taking place within the same COM
> > call, so I'm sure it should be possible.

> > Any help greatly appreciated!  If you could copy any responses to my
> > e-mail address as well as to the newsgroup then that would be most
> > helpful.

> > thanks guys
> > mike

> Make it

> CComObject<CCOMProductDataObject>* pObj;
> HRESULT hr = CComObject<CCOMProductDataObject>::CreateInstance(&pObj);
> // Attention: new object is created with refcount==0
> GetStockInfo gsi(pObj);
> // ...
> return pObj->QueryInterface(result);

> --
> With best wishes,
>     Igor Tandetnik

> "For every complex problem, there is a solution that is simple, neat,
> and wrong." H.L. Mencken

> > > I have a COM service that defines two COM objects.  The first
> > > (ProductDataAccess) creates instances of the second
> > > (ProductDataObject) and then populates them from a database.  To
> > > perform the data population the ProductDataObject needs to be passed
> > > into the constructor of another, non-COM class.  Here is the function:

> > > STDMETHODIMP CCOMProductDataAccess::getData(/*[in]*/BSTR identifier,
> > > /*[out,retval]*/ ICOMProductDataObject** result)
> > > {
> > >   //  create the COM object that we want to populate
> > >   CComPtr<ICOMProductDataObject> myCOMobj;
> > >   HRESULT hr = myCOMobj.CreateInstance(CLSID_COMProductDataObject);
> > >   if (FAILED(hr)) return hr;

> > >   //  now create the non-COM object that will perform the population
> > >   GetStockInfo gsi(myCOMobj);

> > >   //  call function on GetStockInfo class that will populate the COM
> > > object
> > >   gsi->getData();

> > >   //  send the newly populated object back to the client
> > >   (*result) = myCOMobj;

> > >    return S_OK;
> > > }

> > > The prototype of the GetStockInfo class's constructor is:

> > > class GetStockInfo
> > > {
> > > public:
> > >   GetStockInfo(CCOMProductDataObject* obj)
> > >   {
> > >     // load stuff from database
> > >     obj->populate(param1, param2, ..., paramN);
> > >   }
> > > };

> > > However, I don't seem to be able to get the GetStockInfo class to
> > > recognise what the CCOMProductDataObject is.  Am I wrong in thinking
> > > that, in this case, I can just pass the CCOMProductDataObject to the
> > > function and that I don't need to worry about the interface pointer
> > > and stuff like that?  This is all taking place within the same COM
> > > call, so I'm sure it should be possible.

> > > Any help greatly appreciated!  If you could copy any responses to my
> > > e-mail address as well as to the newsgroup then that would be most
> > > helpful.

> > > thanks guys
> > > mike

> > CComObject<CCOMProductDataObject>* pObj;
> > HRESULT hr = CComObject<CCOMProductDataObject>::CreateInstance(&pObj);
> > // Attention: new object is created with refcount==0
> > GetStockInfo gsi(pObj);
> > // ...
> > return pObj->QueryInterface(result);

> > --
> > With best wishes,
> >     Igor Tandetnik

> > "For every complex problem, there is a solution that is simple, neat,
> > and wrong." H.L. Mencken

> Thanks Igor, that's great.  Why don't the books tell me things like
> that?!

> I ended up just passing the interface pointer around and that's
> working fine.  Just got to figure out why my object's crashing when
> it's destroyed now...no doubt I'll be posting here to try and figure
> it out :-)

> My copy of Win32 Multithreaded Programming arrived today.  More
> books....

> all the best
> mike

> > Thanks Igor, that's great.  Why don't the books tell me things like
> > that?!

> ATL Internals [1] does :)

> > Just got to figure out why my object's crashing when
> > it's destroyed now...

> Wild guess: It's Release()'d after CoUninitialize().

> [1] http://www.amazon.com/o/ASIN/0201695898/

> --
> Best regards,
> Kim

> > > > Hi,

> > > > I have a COM service that defines two COM objects.  The first
> > > > (ProductDataAccess) creates instances of the second
> > > > (ProductDataObject) and then populates them from a database.  To
> > > > perform the data population the ProductDataObject needs to be passed
> > > > into the constructor of another, non-COM class.  Here is the function:

> > > > STDMETHODIMP CCOMProductDataAccess::getData(/*[in]*/BSTR identifier,
> > > > /*[out,retval]*/ ICOMProductDataObject** result)
> > > > {
> > > >   //  create the COM object that we want to populate
> > > >   CComPtr<ICOMProductDataObject> myCOMobj;
> > > >   HRESULT hr = myCOMobj.CreateInstance(CLSID_COMProductDataObject);
> > > >   if (FAILED(hr)) return hr;

> > > >   //  now create the non-COM object that will perform the population
> > > >   GetStockInfo gsi(myCOMobj);

> > > >   //  call function on GetStockInfo class that will populate the COM
> > > > object
> > > >   gsi->getData();

> > > >   //  send the newly populated object back to the client
> > > >   (*result) = myCOMobj;

> > > >    return S_OK;
> > > > }

> > > > The prototype of the GetStockInfo class's constructor is:

> > > > class GetStockInfo
> > > > {
> > > > public:
> > > >   GetStockInfo(CCOMProductDataObject* obj)
> > > >   {
> > > >     // load stuff from database
> > > >     obj->populate(param1, param2, ..., paramN);
> > > >   }
> > > > };

> > > > However, I don't seem to be able to get the GetStockInfo class to
> > > > recognise what the CCOMProductDataObject is.  Am I wrong in thinking
> > > > that, in this case, I can just pass the CCOMProductDataObject to the
> > > > function and that I don't need to worry about the interface pointer
> > > > and stuff like that?  This is all taking place within the same COM
> > > > call, so I'm sure it should be possible.

> > > > Any help greatly appreciated!  If you could copy any responses to my
> > > > e-mail address as well as to the newsgroup then that would be most
> > > > helpful.

> > > > thanks guys
> > > > mike

> > > Make it

> > > CComObject<CCOMProductDataObject>* pObj;
> > > HRESULT hr = CComObject<CCOMProductDataObject>::CreateInstance(&pObj);
> > > // Attention: new object is created with refcount==0
> > > GetStockInfo gsi(pObj);
> > > // ...
> > > return pObj->QueryInterface(result);

> > > --
> > > With best wishes,
> > >     Igor Tandetnik

> > > "For every complex problem, there is a solution that is simple, neat,
> > > and wrong." H.L. Mencken

> > Thanks Igor, that's great.  Why don't the books tell me things like
> > that?!

> > I ended up just passing the interface pointer around and that's
> > working fine.  Just got to figure out why my object's crashing when
> > it's destroyed now...no doubt I'll be posting here to try and figure
> > it out :-)

> > My copy of Win32 Multithreaded Programming arrived today.  More
> > books....

> > all the best
> > mike

> Does it?  I couldn't find it in there, although admittedly I don't
> have an intimate knowledge of the book.  If there were 50 hours in a
> day, then maybe...