Hi,

I'm returned from the vacations, and I resume to ...

TYPE() VFP function have a bug when you use to UDF.

TYPE(' udf() ') not evaluate the udf(), but search for an Array

? EVALUATE('MyRef(1)')
? VARTYPE(MyRef(2))
? TYPE('MyRef(3)')
? TYPE(MyRef(4))
? '-------------'
? EVALUATE('MyRef[1]')
? VARTYPE(MyRef[2])
? TYPE('MyRef[3]')
? TYPE(MyRef[4])

DIMENSION MyRef[1]
MyRef[1]='ARRAY'

? EVALUATE('MyRef(1)')
? VARTYPE(MyRef(1))
? TYPE('MyRef(1)')
? TYPE(MyRef(1))
? '-------------'
? EVALUATE('MyRef[1]')
? VARTYPE(MyRef[1])
? TYPE('MyRef[1]')
? TYPE(MyRef[1])

PROCEDURE MyRef(z)
 ? 'call ',z && non viene chiamata da TYPE('MyProc()')
 RETURN 'ZUPPA'
ENDPROC

This problem derives from a sin originates made them in VFP3:

it is possible to use () and [] it is for the Array, it is for the UDF;

this ambiguity creates remarkable problems to the VFP Team,
why the parser it must or resolve (slowing down) or to ignore it.

An Array has priority on a UDF, but a VFP function can have priority on an Array:

 date=5 && no problem
 DIMENSION date[1] && it is ambiguous, therefore VFP generates an error

If [] the VFP were exclusive of the Array Team would have saved a sea of controls and possible others bugs.

VARTYPE() suffers from others correlate bugs.

After all an unique command does not exist in order to control existence, accessibility and type of one variable, Array, property, method, udf, expression.

To correct this error after VFP3, VFP5, VFP6, VFP7, VFP8 becomes critical; the only solution is to add to an option like
SET COMPATIBLE TO VFP9
with which the use of [] is shrunk for the Array and () for the UDF.

Fabio