Hi Christof,

Well COOL is not the word I would use to describe the situation, since that word is typically (at least in my usage) reserved for NEAT things with *good* attributes.

Furthermore, had all this been known ahead of time, I wonder WHY it does not appaer in the Help. I just checked it and there was absolutely no mention of such as you have described (unless it was 'behind' something, which I did not check).

It is UNcool, in my humble opinion, for any command/function/etc to deliberately cause any EXCEPTION at any time.

The VFP folks here (and elsewhere, presumably) are the most docile that I have come across. If something like this doesn't get them speaking out, then I guess nothing ever will!

Regards,
Jim N

>Hi Jim,
>
>>I hope that the powers that be reconsider this stand.
>
>That's the problem. They did.
>
>The reason why VARTYPE() is faster as TYPE() is that TYPE() requires an evaluation of the expression at runtime. VARTYPE(), OTOH, can be evaluated (to be precise: tokenized) during compiling. You can say that:
>
> TYPE("Variable") == VARTYPE( EVALUATE("Variable") )
>
>But later, when some people complained about it, an exception handler (or sort of, I'm not the programmer) was added to capture not existing variables and return "U" in that case. Since usually VFP evaluates parameters before it passes them to the function, with the exception of array functions, this must have required some extra code on a higher level then the actual function. Thus, we have side effects like VARTYPE() not working this way with:
>
>a) references that are created by VFP when there's an appropriate object, like ActiveForm, ActiveControl, Parent, etc.
>
>b) with OLE controls. VARTYPE(_VFP.Blah) causes an OLE exception error
>
>c) with properties that are adressed via a not existing reference, like VARTYPE(Thisform.oObject.Property) when oObject is NULL.
>
>Doesn't the English language have a word for that: Cool! < eg >
>
>
>Christof