--- In [email protected], "entropyreduction" <alancampbelllists+ya...@...> wrote: > > 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
Invoke with all strings applies only to guessed parameters, and guessed parameters are only those that are VARIANTs in the typelib, Right?? > > > > 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. Maybe that is because you had failed to copy it into a VARIANT using CComBStr.CopyTo ! <http://msdn.microsoft.com/en-us/library/19hbst0w%28VS.80%29.aspx> <http://msdn.microsoft.com/en-us/library/bdyd6xz6%28VS.80%29.aspx#programmingwithccombstr_scopeissues> Then when the BStr goes out of scope it will destroy itself, but the cargo for the VT_BSTR will survive. Regards, Sheri
