>>>Seems to me that if there is an 'encapsulated' way of doing things, than it should be done that way.
>>
>>_Tally is a read-only property of the global system object, where the object is implied.
>>
>>Does that interpretation make it more palatable? :)
>
>cute.
>so in C++ speak
>::_Tally
>
>VFP really needs a system object.
>
>fox._Tally ?
>fox._screen.autocenter = .T.

Samuel,

There is the VFP object and _SCREEN is an object. The system variables are not connected to any object, they are memvars. They are declared and present whether you use them or not.

You are correct in feeling that global variables re not a great idea, but it is important to understand why they are not a good idea. When we declare a variable PUBLIC we state that the variable will be referred to by a routine that is above the one doing the delcaration. This indicates that some routine somewhere is referring to a variable that it (or a higher level routine) does not delcare. This causes a tight external coupling of the routines, meaning changes made to one require visiting and updating other routines. This causes maintenance problems.

Using the VFP system variables in another story, since you are guarantteed that the system variables will always exist and that their names will never change.

Cetin told you of a problem with _TALLY and non-machine collating. I will tell you that RECCOUNT() does not always accurately tell the number of records that met your where clause. In situations where VFP will filter the original table to obtain the SQL results the RECCOUNT() will be the number of records in teh table (including deleted records) while _TALLY will be the number of records that met the where clause.