[out, retval] is not valid in a dispinterface. It's intended to be used
BTW, HRESULT is synonymous with void in a dispinterface.
other dispinterfaces. Your implementation uses HRESULT of
for JavaScript clients. You should use [in, out] arguments
return values of multiple client sinks. See this FAQ article:
Igor Tandetnik wrote:
Is that your actual IDL declaraion? Is your event interface a
dispinterface? I don't believe a dispinterface method can have both a
non-void return type and an [out, retval] parameter. Don't you get any
warnings or errors from MIDL compiler?
Hi Igor. First, thanks for your time.
This is the relevant part of my IDL:
dispinterface _IApplicationEvents
{
properties:
methods:
[id(1), helpstring("method NewMessage")] HRESULT NewMessage([in, string]
BSTR message, [in] long length);
[id(2), helpstring("method ApplicationOutOfService")] HRESULT
ApplicationOutOfService([in] REASON_OUT_OF_SERVICE reason);
[id(3), helpstring("method QueryClientStatus")] HRESULT
QueryClientStatus([out, retval] VARIANT_BOOL* status);
};
The third method is the one that gives me trouble. MIDL 6.00.0361 gives
me no warning about it.
Note that dispinterface methods (unlike most other COM methods) don't
have to, and generally shouldn't, return an HRESULT. What appears in the
IDL as the return value is actually returned via pVarResult parameter to
IDispatch::Invoke. IDispatch::Invoke can also return an HRESULT - this
is implied and is not reflected in the IDL declaration.
[snip]
My guess would be, VARIANT_BOOL is used as return type, HRESULT is
ignored, and there are no parameters. Try
VARIANT_BOOL __stdcall OnQueryClientStatus();
_ATL_FUNC_INFO CInteractionManager::EvtQueryClientStatus =
{CC_STDCALL, VT_BOOL, {}};
Finally, after some attempts to make [out, retval] work, I went with the
above suggestion.
I changed the event to be like this:
[id(3), helpstring("method QueryClientStatus")] VARIANT_BOOL
QueryClientStatus();
My firing code is this:
HRESULT Fire_QueryClientStatus(VARIANT_BOOL* result)
{
CComVariant varResult;
T* pT = static_cast<T*>(this);
SuscribedSinks::iterator iter = m_sinks.begin();
*result = VARIANT_TRUE;
while(iter != m_sinks.end()) {
pT->Lock();
CComPtr<IUnknown> sp = (*iter).pUnkSink;
pT->Unlock();
// este m?todo debe ser implementado OBLIGATORIAMENTE
IDispatch* pDispatch = reinterpret_cast<IDispatch*>(sp.p);
if (pDispatch != NULL) {
EXCEPINFO excepInfo;
UINT argError;
VariantClear(&varResult);
DISPPARAMS disp = { NULL, NULL, 0, 0 };
HRESULT hr = pDispatch->Invoke(0x3, IID_NULL, LOCALE_USER_DEFAULT,
DISPATCH_METHOD, &disp, &varResult, &excepInfo, &argError);
if(FAILED(hr)) {
*result = VARIANT_FALSE;
break;
}
else {
varResult.ChangeType(VT_BOOL);
if(varResult.boolVal == VARIANT_FALSE) {
*result = VARIANT_FALSE;
break;
}
else if(varResult.vt == VT_EMPTY) {
*result = VARIANT_FALSE;
break;
}
}
}
++iter;
}
return varResult.scode;
}
And the sink in C++ is defined like this:
_ATL_FUNC_INFO CInteractionManager::EvtQueryClientStatus = {CC_STDCALL,
VT_BOOL, 0};
VARIANT_BOOL __stdcall OnQueryClientStatus();
Now it works with clients written in C++, Visual Basic and Lua (with
LuaCom). I've settled with this solution. Do you see something that may
lead to trouble going with this approach instead of using [in, out]
parameters?
Regards,
Ignacio Burgue?o