Hi!

I read all the opinions...

Well, it actually evaluates not all of built-in functions as well. I attempted to find a workaround and comed to following:

cStr = "trimzero('00034')"
? type("evaluate(cStr)")

Above returns "U"... So, evaluate() also does not works with UDF's when it is inside of type(). VFP also does not run any methods of objects as part of TYPE(). for example, "_Screen.AddProperty('aa',2)" does not works inside of TYPE(), and result of TYPE() is "U".

I found only one workaround to check what is a type of data that UDF or method returns:

cStr = "trimzero('00034')"
? vartype(evaluate(cStr))

However, you should be sure errors are disabled because you now could not know if that function can throw an error, and if it evaluates into correct expression.

So, after all, I'm thinking too that type() does not accepts UDF's only for one reason - to exclude any circumstanses inside of type() that can bring VFP to crash or throw error or run any command that bring VFP to hang up.

It would be good to have more advanced type() - returntype() function, that would run methods and UDF inside to check what is returned type, but also disable any erros, as well as disable any commands/functions/methods running that might cause critical environment changes. Indeed, such function would be useful allow users define custom expressions and use pre-prepared UDF's there, but exclude possibility to crash VFP.

Just dreaming...

Is it worth to add into the wishes list?

HTH.

>>Unfortunately, as I just found, type doesn't return correct results, if UDF is used, e.g.
>>type("trimzero('00034')") returns U, while vartype(trimzero('00034')) returns C (trimzero is custom function, which removes leading 0s).
>
>I have seen this problem a few years ago in FoxPro. As to the reasons, I came to the following conclusion:
>
>For a built-in function, VFP (or FoxPro) knows the expected return type. The type can be determined without actually evaluating the function.
>
>For a UDF, there is currently no way to tell VFP that your UDF normally returns such-and-such a type. There is no way for VFP to tell you the type of the expression without actually calling the function. This may have undesirable side-effects: your UDF might do almost anything, or produce an error.
>
>For these reasons, although it is unpleasant not to be able to easily get the type of your expression with type(), I find VFP's behavior perfectly logical.
>
>Regards,
>
>Hilmar.