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

> > Yeah, they're saying in help what they expect the Variant to turn
> > out to be. Hopefully they will have done the Right Thing in their
> > code, so when e.g. the code for Search function runs, it will
> > take whatever comes in first parameter and coerce it to a BSTR,
> > whatever comes in as thirst param and coerce it to bool, etc.
 
> If that were the case, how would you explain the com exception errors I got 
> previously when the search text happened to be all digits (unless I used the 
> method_typed service instead)? I also recall errors setting properties in 
> another service whose paramether needed the type to be a "double". Given 4.0, 
> it gave a com exception. But given 4, it worked. Using method_typed, I could 
> use 4.0. The property in question does not appear use variant, it has (per 
> vbaccelerator TLBHelp's Browse tab)

Depends on what you mean by "previously".  Before I started trying to detect 
the expected parameter type (i.e. in version I'm working on now), I tried some 
very crude guesses on what datatype was required for a particular parameter; if 
that crude guess failed, exception.

I'm still not entriely sure what happens when server declares a paramter 
VARIANT.

 
> Public Property Let Version(RHS  As Double) 'Version of the scripting 
> environment
> 
> Don't know what RHS means, but I don't see any "Variant" there.

In current version, once I get code right, my code should see that
requirement, same as TLBhelp does, and convert the incoming string from 
Powerpro to a double.
 
So, try comPlugin0.72_091207.zip
in
http://tech.groups.yahoo.com/group/power-pro/files/0_TEMP_/AlansPluginProvisional/

Parameter typing my now work.

Unicode might now work; seems to for the included
comPluginDemoScriptFileSysObjDotSyntaxForEach.powerpro




Reply via email to