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)
>>>?TYPE("Var")
>>>
>>>
>>>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'))
>>
>>?type("trimzero('123')")
>>
>>?vartype(trimzero('123'))
>>
>>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?
If it's not broken, fix it until it is.
My Blog