VO Argument to OLE Variant problem
Stephane Hebert
The generated code of some OLE method asks for a ptr, but I can't seem to be
able to supply it.
Here is the example in VB, where m_control is an IMemory object.
set m_control=m_Prod.GetFull(fControl)
timing=m_prog.InitEx(fLeft,m_control) <<--- arg 2 here
Here is how InitEx is implemented...
Method InitEx(;
ear,;
control,; // AS PTR
) Class IProgrammer2
// Initializes a connected device.
...and here's what I'm doing:
local oControlMem as usual // ptr // IMemory <<-- I tried a couple
of things here <g>
local nTiming as long
oControlMem:=oCache:Product:GetFull(fControl1) <<<-- This works. I
know it works cause I can access some
methods/accesses of oControlMem.
nTiming:=self:oProgrammer:InitEx(nEar,oControlMem) <<<-- Arg 2 here
just won't work.
nTiming:=self:oProgrammer:InitEx(nEar,ptr(_cast,oControlMem)) <<<--
nope
nTiming:=self:oProgrammer:InitEx(nEar,long(_cast,oControlMem)) <<<--
nope
I keep getting an VO Argument to OLE Variant error.
What else is there to try ?
Steph
Stephane Hebert
TypeLib:
[id(0x60040000), helpstring("Initializes a connected device.")]
HRESULT InitEx(
[in] EarConstants ear,
[in, out] IMemory** control, // VO says that this is PTR, but won't
accept a PTR.
[out, retval] long* rval);
Thanks
"Stephane Hebert" <sgtp...@bootcamp.com> wrote in message
news:fgxB8.27938$8V6.9...@news.webusenet.com...
Karl-Heinz Rauscher
> oControlMem:=oCache:Product:GetFull(fControl1) <<<-- This works. I
> know it works cause I can access some
>
> methods/accesses of oControlMem.
> nTiming:=self:oProgrammer:InitEx(nEar,oControlMem) <<<-- Arg 2 here
> just won't work.
if i have similar problems i avoid the usage of the generated method /
assign etc. Therefore i would rename the generated Method InitEx() to let´s
say _InitEx() and try something like this :
nTiming:=self:oProgrammer:InitEx(nEar,oControlMem)
or maybe:
nTiming:=self:oProgrammer:InitEx(nEar,oControlMem:__IDispatch )
--
regards
Karl-Heinz
Stephane Hebert
I tried your suggestions, but they didn't work.
I changed InitEx to _InitEx and recompiled before changing the call, so
naturally the complier complained that InitEx didn't exist.
I changed my cal to _InitEx() and this time evrything compiled. But at
runtime, I got a NoMethod error when calling _InitEx().
I also tried __IDispatch, but no good.
Here is what VO generated for InitEx. So how should I handle VT_PTR ?
Method InitEx(;
ear,;
control,; // AS PTR
) Class IProgrammer2
// Initializes a connected device.
LOCAL a AS ARRAY
LOCAL pFirstParamDesc, pParamDesc AS VOOLEARGDESC
LOCAL pRetDesc IS VOOLEARGDESC
LOCAL uRetValue AS USUAL
a := {String2Symbol("InitEx"), 1610874880, INVOKE_METHOD, 2, 0, .T., ,
@pRetDesc}
pParamDesc := pFirstParamDesc := self:__AllocArgDescs(2)
a[OFD_PARAMDESC] := pParamDesc
pParamDesc.dwIDLFlag := 1
pParamDesc.dwVarType := VT_USERDEFINED
pParamDesc.atomArgName := #ear
pParamDesc += 1
pParamDesc.dwIDLFlag := 3
pParamDesc.dwVarType := VT_PTR
pParamDesc.dwArrPtrType := VT_PTR
pParamDesc.atomArgName := #control
pParamDesc += 1
pRetDesc.dwIDLFlag := 0
pRetDesc.dwVarType := VT_I4
uRetValue := self:__InvokeMethod(a, DWORD(_bp+16),PCount())
MemFree(pFirstParamDesc)
return(uRetValue)
Thanks
Steph
"Karl-Heinz Rauscher" <khrau...@compuserve.com> wrote in message
news:ab6guk$fmkcs$1...@ID-61886.news.dfncis.de...
> Steph(ane) <s>
>
> > oControlMem:=oCache:Product:GetFull(fControl1) <<<-- This works. I
> > know it works cause I can access some
> >
> > methods/accesses of oControlMem.
> > nTiming:=self:oProgrammer:InitEx(nEar,oControlMem) <<<-- Arg 2
here
> > just won't work.
>
> if i have similar problems i avoid the usage of the generated method /
> assign etc. Therefore i would rename the generated Method InitEx() to
let愀
Karl-Heinz Rauscher
> But at runtime, I got a NoMethod error when calling _InitEx().
not sure, if i understand correctly, you´re using _InitEx() ?? If that´s
the case it´s wrong. You still must call InitEx(). You might get a compiler
warning but ignore it, because InitEx() will be resolved now at *runtime* .
The trick is to bypass the *generated* InitEx() code , therefore i mentioned
to rename ( and deactivate ) the generated InitEx() with a
leading underscore.
Therefore please try it again
Stephane Hebert
Ok. Tried it again with changing only the generated method from InitEx to
_InitEx.
Still the same. Works great from VB BTW.
VO really sucks when it comes to OLE stuff.
I guess I'll have to go back to making VB wrappers for OLE stuff, just like
I did last year. I'm loosing valuable time over this and I'm really not
inclined into learing the ins 'n' outs of OLE/COM.
Brian ? Will ya get this shit fixed asap please ?
Just letting a little steam out. Kind of feels good ;)
Thanks Karl.
Steph
"Karl-Heinz Rauscher" <khrau...@compuserve.com> wrote in message
news:ab6mup$fluh8$1...@ID-61886.news.dfncis.de...
Karl-Heinz Rauscher
>> Still the same.
sorry to hear, but without those OleAutoObject(s) installed i have no other
idea.
>> Works great from VB BTW
yep, i´m sorry <g> to confirm the VB OLE features, but VO is *really* years
behind other languages like VB and Delphi when OLE/COM features are needed.
1. *no* automation server events ...
2. *no* for each ... next support.
3. As Rod mentioned several times, a useless QueryInterface implementation
4. Bugs in the current ole sources that might be really show stoppers, or at
least they blow up each time calculation in finding workarounds ....
but i´m sure Brian knows about all that crap, and what features are needed
to call a language modern.
Stephane Hebert
> but i´m sure Brian knows about all that crap, and what features are
needed
> to call a language modern.
Yeah I know, I'm sure he does to and he doesn't need to be reminded, but
letting the steam off felt good <g>
Not only didnt this bit work, but I'm sure I wuold have hit more brick walls
as I advanced. One thing I discovered was that the implementation of the OLE
server I'm working with now uses the ISupportErrorInfo Interface for error
reporting. As the docs supplied say:
[SNIP]
Exception handling in ARK is handled through the standard COM
ISupportErrorInfo interface which is used by Visual Basic and other
languages ( but not VO, right ?). This allows ARK error handling to
integrate well with these languages.
[SNIP]
So I guess I would have been screwed here too.
Steph
Karl-Heinz Rauscher
>> Exception handling in ARK is handled
>> through the standard COM ISupportErrorInfo
>> interface which is used by Visual Basic and other
>> languages ( but not VO, right ?).
yes it愀 the VO-programmers job to implement this interface ....
BTW. Though personally i don愒 like the VFP language / syntax at all - and
therefore only for information <g> - an interesting VFP 7.0 OLE / COM
enhancement overwiew.
http://msdn.microsoft.com/msdnmag/issues/01/10/VFP7/VFP7.asp
it seems that now even VFP has more to offer than VO ... ( in this area
only, of course <g> )