--- In [email protected], "Sheri" <sheri...@...> wrote:
> 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. I've run into a fair number of COM servers who can't cope with string arguments in, so I incorporated type-guessing quite early on. I'll continue to implement it (mow on a one-at-a-time, post-failure basis) but you'll be able to turn it off and on (so you get full force of mismatch error messages) with both a serivce call and a config ini key. > > 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> I use I use ::SysAllocString(L""): CComBStr(L"foo") would destroy itself too soon. > > (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, OTOH, rather like it. > > > 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> Not relevant. I'm not doing managed code. > 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. If it works, great. > 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 Okay, too bad, dunno what's going on there and don;t see how to fix it. > 2. InDesign Search method is erroring on Parameter #2. I guess since the > guess methodology is unchanged, no change s/b expected here. Correct, no change expected there. > 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> Irrelevant. I'm making no attempt to retrieve any value that might be returned via a ByRef parameter, so I don't care what type the server might turn it into. If you find a situation where retrieving byref returned values is necessary, let me know. Inn PP it would have to be done by passing the name of a variable in place param was expected.
