--- In [email protected], "Sheri" <sheri...@...> wrote:
>
> --- In [email protected], "entropyreduction"
> <alancampbelllists+yahoo@> wrote:
>
> > Yeah, that makes sense. Remember, I do two passes. You see error
> > message for second pass. Pass I: Guess. Pass II: send everything
> > in as strings (logical order: I keep track of whether any
> > parameter was converted by guess in pass one: if no such
> > conversion made, no point in Pass II).
>
> If you don't even know which, or even if, its an argument type that is in
> error, making multiple passes makes no sense to me.
I know it's an argument error, because of what IDispatch::Invoke returns.
> Now that you are getting errors that the user can act on, I think it would be
> best if you did the same. Maybe we should try a no-guess model again.
Not quite. If IDispatch::Invoke returns DISP_E_TYPEMISMATCH or one of several
other error codes, _if_ the server code works as it should
it should return argument number in puArgErr argument. In my experience,
servers don't always do what they should, but yes, I'm considering confining my
guessing to specific arguments nominated by
*puArgErr. That means
(1) call to IDispatch::Invoke with all strings
(2) if that fails with a DISP_E_TYPEMISMATCH and apparently valid
*puArgErr, (which hopefully will only happen with VT_VARIANT VAARIANTS, guess a
type other than string.
(3) If IDispatch::Invoke fails again with DISP_E_TYPEMISMATCH and apparently
valid *puArgErr other than previous *puArgErr, repeat
One problem with this design is multiple calls to IDispatch::Invoke, which is a
very heavyweight call, and therefore can be very slow. If someone drops in a
15-argument method call, all taking VT_VARIANTs mean to be, e.g. booleans, and
the server code isn't well written so strings aren't accepted, that's 15
IDispatch::Invoke call. Do that in a loop and you've probably got molasses
> I believe you are calling functions that will try to coerce what is needed
> from the VARIANTs received. But for whatever reason, sometimes the called
> functions can't do that. Maybe it can't do it if you send it a specific type
> in the variant. Maybe it needs a VT_VARIANT and VT_VARIANT can only be sent
> as VT_BYREF. Presumedly the pointer can point to a Variant of a specific type
> such as VT_BSTR. The other possibility it has something to do with which
> process the Variant data lives in. Either way, using VT_VARIANT|VT_BYREF
> could be the answer.
VT_BYREF is a whole other issue. If the typeinfo for an argument doesn't
indicate that an argument is to be passed by reference, it's not a great idea.
But I'll try.
BTW with pVarParam (VARIANT*) set up as a VT_BSTR, containing "1", this works:
hr = VariantChangeTypeEx(pVarParam, pVarParam,
GetUserDefaultLCID(), 0, VT_BOOL);
ergo whoever wrote search method forgot to use VariantChangeTypeEx or
VariantChangeType in the code that implements.
> >
> > I think you did local r=myselect.Search(chgVec[i,1], wholeword,
> > casesensitive, chgVec[i,2]) equivalent in vbs and it worked?
> I can't really model Powerpro's regex to 2d vector into vbscript. Vbscript,
> if passed 123 instead of "123" for parameter #1 of the Search method gives an
> Indesign error message for Parameter #1. You could now do the same.
Try comPlugin0.72_100120.zip. For optional VT_VARIANTs, no longer attempts to
populate with defualt value, if any. Doesn't make any other changes, i.e.
still using 2-pass IDispatch::Invoke system
