Re: Best way to send Structs through COM interface?
Barzo <email@example.com> wrote:
2) In the Connection Point implementation, can I pass the struct by
value to avoid problems?
HRESULT Fire_OnError( T_ErrorInfo error_info )
You can, but I don't quite see how it helps. Precisely what kind of
problems is this supposed to avoid?
3) In the Fire_OnError body I wrote:
hr = GetRecordInfoFromGuids(LIBID_AxEuroATLib,
avarParams.vt = VT_RECORD;
avarParams.pvRecord = &sds_info;
avarParams.pRecInfo = pRI;
pRI = NULL;
Now I remember what the deal is with UDTs. When you pack a UDT into a
VARIANT, and later call VariantClear on it (which CComVariant's
destructor would do automatically in your case), VariantClear does three
1. Calls IRecordInfo::RecordClear on your struct. This would deallocate
any fields that require deallocation (such as BSTR fields you have).
2. Releases IRecordInfo pointer.
3. Deallocates the struct itself with CoTaskMemFree (under assumption
that it was allocated by CoTaskMemAlloc).
So you have two options. Either you clean up with VariantClear, then you
need to allocate your struct with CoTaskMemAlloc. Or you avoid
VariantClear (by using plain VARIANT rather than CComVariant) and
perform steps #1 and #2 manually, then the structure can be allocated in
any way you want, including on the stack.
That works, and in VB I receive the event but, when I access to the
UDT it crash:
Private Sub MyObj_OnError(error_info As AxEuroATLib.T_ErrorInfo)
Debug.Print "ERROR : " & error_info.Description <<<<<< CRASH!!!!
Have you noticed the part of my previous response where I pointed out
that you are passing garbage pointers instead of valid BSTRs?
With best wishes,
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925