[reordered somewhat]
>However, I suppose CreateComValue could accept the value (and I think it might actually be there already and I just forgot).
>

>LOCAL loNet as Westwind.WebConnection.TypePassingTests
>loNet = loBridge.Createinstance("Westwind.WebConnection.TypePassingTests")
>
>*** Pass parameters by Reference
>*** Create ComValue objects for each parameter
>loInt = loBridge.CreateComValue(INT(10))
>loString = loBridge.CreateComValue("Hello World.")
>loDecimal = loBridge.CreateComValue(CAST( 5.22 as Currency))
>

Works for me as well - had considered it, and the .CreateComValue[Type] methods only won because of the even stronger self-documenting added for the casual reader.

>Usually I would agree brevity, but in this case there are about 10 (and there will probably more) of these things and they are already handled and special cased on the >ComValue object. The reasoning here is that you have the specialized behavior on the object that handles it.
>Additionally you only need to assign the casts if you're using types that require them. If you're assigning a string or boolean or date there's no cast.

The casting in a .CreateComValue[Type] was in part influenced from scenarios where boolean logic was mapped via #define to things particular backends implement. Forcing the numeric value from schema put in by overworked maintainer instead of comparison to #defined BackendTrue into boolean logic as an example ;-)

>There are a also explicit methods that cast to types that FoxPro doesn't support:

>loLong = loValue.SetLong(10)
>loSingle = loValue.SetSingle(1.231)
>loDbNull = loValue.SetDbNull()
>

>
>which is why I tend to be explicit in the examples to make it clear that there's an object that has a number of operations you can perform on it to get around FoxPro's type limitations.

These would be the different [second] lines ;-)).
I would probably have gone the same way as you, having methods on 1 class, making that class a god class in a very minor way (half-god class???), and not creating a minimally different class for each type to be passed as reference with a .SetSpecial method .

The DbNull might make me reconsider that and check if there is further common stuff in the numeric data types warranting a common numeric middle class and, if/while adding different type classes, adding things that make a DbNull class nearly static. But that is just gut reaction without having seen the rest of your code and trying to guess at the problems encountered ;-))

thx for letting us peek at your code - I enjoy it

thomas