|
|
Hi,
I don't really know very much about ActiveX, but I've hit a problem with the
generated wrapper methods that *looks* as if it might be a bug.
This turned up while I've been trying to use wrappers generated for the:
DirectX 8 for Visual Basic Type Library
control (%System32%\dx8vb.dll). It looks as if there are a fair number of
cases where Dolphin has generated correct (private) wrappers for the raw
functions, but the "convenient" (and public) methods don't work.
Perhaps it's a problem with MS's IDL rather than Dolphin, but anyway an example
is the generated wrappers for DirectSound8.GetCaps().
According to the wizard, the IDL for this is:
=================
[
object,
uuid(9F76FB00-8E92-11D1-8808-00C04FC2C603),
helpstring("DirectSound Interface"),
helpcontext(0x0004c450)
]
interface DirectSound8 : IUnknown {
....
[id(0x60010005), helpcontext(0x00013fa3)]
HRESULT __stdcall GetCaps(
[in, out] DSCAPS* Caps);
....
};
=================
And the "raw" wrapper that's generated is:
=================
GetCaps: caps
"Private - Invoke the GetCaps() method of the COM object.
HRESULT __stdcall GetCaps(
[in, out] DSCAPS* Caps);"
<virtual stdcall: hresult 9 DxVBLibADSCAPS*>
^self invalidCall
=================
And that works fine. But the corresponding public method is:
=================
getCaps: caps
"Invoke the GetCaps() method of the COM object."
^self GetCaps: (DxVBLibADSCAPS new value: caps; yourself)
=================
Which doesn't work because it throws away the data that Windows writes into the
new DSCAPS object, rather than updating the DSCAPS object that's passed in by
the caller. BTW, is the idea of allocating new DSCAPS object supposed to make
it possible to pass nil as the parameter ? If so then that doesn't work either
:-(
-- chris
|
Locked
