>>>Nadya,
>>>
>>>TYPE() works perfectly. It returns the type of an expression. The expression "SomeUDF(123)" is character because "someudf(123)" is a literal string when "SomeUDF(123)" is evaluated it becomes SomeUDF(123) which is a string of characters.
>>>
>>>However TYPE(SomeUDF(123)) will retunr the type of the value that evaluating the expression results in, so if the UDF retuirns Character then the TYPE will retunr C.
>>>
>>>This is why;
>>>
>>>

>>>Var = 123
>>>?TYPE(Var) && N && Theexpression Var evaluates to 123 which is a number
>>>?TYPE("Var") && C The expression "Var" evals to Var which is a string
>>>

>>>
>>>There is nothing wrong with the TYPE() function it just takes some study to fully underatand how it works.
>>Jim;
>>In VFP6 SP5
>>

>>var = 123
>>?TYPE(var) && generates function argument value, type or count invalid error
>>?TYPE("var") && returns "N"
>>?VARTYPE(var) && returns "N"
>>?VARTYPE("var") && returns "C"
>>

>>This is how type() function has worked in previous versions,has this changed in VFP7 and above?
>
>I think his Var=123 was just a typo and should have been Var="123"
>
>Alan

The Help states:

Evaluates an expression and returns the data type of its contents.

Syntax

TYPE(cExpression)

Returns

Character

Arguments

However, in case of UDF it doesn't evaluate expression, e.g. it's not the same, as evaluate function.

?evaluate('trimzero("123")) && returns 123 - character expression
?type('trimzero("123")) && returns U - e.g. it didn't try to evaluate content.

I was unaware of this behavior. Anyway, once I found it, I made a simple fix using macro substitution.

The similar problem exists with GetExpr dialog, BTW. It also can not work with UDF (the error is different, though) Mike Asherman found this problem few years ago, it's some VFP limitation...