--- In [email protected], "Sheri" <sheri...@...> wrote:
>

> Have now tried putting the boolean arguments into unicode handles. That 
> doesn't work (I get com exceptions). Presume that unicode is always being 
> sent as strings. (fine with me).

Yes. And that strongly suggests that recipient application is not handling its 
incoming variant arguments correctly.  It it were, it would cast whatever came 
in to a VT_BOOL, probably using VariantChangeType.


> > Would that be all the time, or only when the string in question
> > is all digits?
> > 
> > If the former, weird, because if (a) argument is a VARIANT AND
> > (b) string providied is not apparently a real or integer, it's
> > sent in as a BSTR, i.e. a wide string.
> 
> Don't understand the question. My actual test processes the search and 
> replace strings stored in a 2d vector. The vector was created via regex 
> plugin. There are four rows in the vector. One of the two values in the first 
> row is all digits.

Okay, so _my_ code, in the version of com you have, sees that string of digits 
(unless it's contained in a unicode string signalled by a unicode handle), and 
guesses that you want a VT_I4, so uses VariantChangeType to make it so.  
Clearly your receiving application is unhappy with a VT_I4, but happy with a 
VT_BSTR (which is what it gets it you pass in a unicode handle: unicode handle 
trumps sequence of digits).

Let't just test that.  comPlugin0.72_091218_no_guesses.zip in the usual place 
is exactly the same as comPlugin0.72_091217.zip, except
in cases where arguments types are not known (VT_VARIANTs), it does _not_ 
attempt to guess type based on string contents, but leaves as a VT_BSTR.  That 
may break other calls to other methods, but for now, does that fix your 
myselect.Search calls?
 
 
> [..snip..]
> 
> > Nope, that's what VARIANT means. It's recipient's responsibility
> > to provide translation of whatever actual type comes in to the
> > type it wants. 
 
> Maybe you have to send it as "Unknown" type for recipient to be able to do 
> that?

No, that couldn't work.  To convert a VARIANT, you _must_ know what type of 
data it contains.  

> Do you think functions such as com.string(variable), com.double(variable), 
> etc., would be worthwhile?

Well, com.string would be the default: everything is taken to be a VT_BSTR 
(since that's what powerpro send me, strings).  com.double, com.bool, etc are 
certainly possible and very easy to do.  But is it syntactically less painful 
to use such services, are simply revert to the com*_typed services?



Reply via email to