--- In [email protected], "entropyreduction" <alancampbelllists+ya...@...> wrote: > > --- In [email protected], "Sheri" <sherip99@> 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.
What I meant there was not that you should try to act on user errors, but show user the user error. Given the available message, user could either change the script to utilize unicode for the string in question (Search method's Parameter #1), or use a typespec. We see much more info now than Invoke Failed com exception. > > 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 Strings might be tricky <http://www.devguy.com/fp/Tips/COM/#BSTR> > > (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 Ya, I really dislike that idea. > > > 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. "In Visual Basic, ByRef semantics are added automatically for every implicit late binding call." <http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.variantwrapper.aspx> > > 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. > They do have another way to set those would-be parameters as defaults, where the types are specific in the Type Library. So, four statements to set all the needed values, then Search() with no arguments. > > > > > > 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 > Timestamp on com.dll in comPlugin0.72_100120.zip is early on 100119 so possibly a mixup. However no change in either of my recent tests: 1. Excel checkspelling method - "skipped" dictionary (which should cause existing default dictionary to be used and retained), is still being treated like an empty string 2. InDesign Search method is erroring on Parameter #2. I guess since the guess methodology is unchanged, no change s/b expected here. Concerning VT_VARIANT|VT_BYREF, dot net has a variantwrapper class to utilize it. "One advantage of using VT_VARIANT | VT_BYREF variant types is that the type of data can be changed during a method call. For example, you can pass a VT_VARIANT | VT_BYREF variant type that contains a VT_BSTR and get a variant returned that contains a VT_I4 after a method call." <http://msdn.microsoft.com/en-us/library/system.runtime.interopservices.variantwrapper.aspx> Regards, Sheri
