Thanks, Boban. I don't know, what to say. Is it by design?

I've just re-read help on type() function and also Hacker's Guide for VFP6, but didn't find anything explaining this behavior.

>I have tried that on VFP 7.0 and it also returns U.
>
>>>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,
>>
>>I'm using VFP6. Here are my results:
>>

>>?type(trimzero('123')) && N && trimzero returns "123", so type of it would be N (type('123') - works
>>
>>?type("trimzero('123')") && U - Here I expected C to return
>>
>>?vartype(trimzero('123')) && C

>>
>>How would you explain U result? I tested on other UDFs and all return U. However, type("val('123')") correctly returns N. Type('str(123)') also returns C, which is correct.
>>
>>Only UDFs don't work, as I expected them to work. VFP6 SP4
>>
>>Do you have different results in VFP7?