Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Register Log in
  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Why do single letter Object variables behave unpredictably?

Debugging and Tuning

Why do single letter Object variables behave unpredictably?

by  wgcs  Posted    (Edited  )
The old way Xbase dealt with the "USE" areas (before the concept of an "alias" was created) was to use single letters to identify them:
Code: 
SELECT 1 = SELECT A
SELECT 2 = SELECT B
all the way to
Code: 
SELECT 12 = SELECT L
THEN, there was "M", which was reserved for memory variables. (I don't remember if it continued with 14="N" or not)

These could be used as aliases are used now, since they didn't have aliases yet:
Code: 
SELECT 1
USE Customer
SELECT 2
USE Order
IF B.Ord_Cust=A.Cust_Num
  * Do this
ENDIF

So, This can get confusing if you use single letter names for object variables, since a table in Select Area 1 that has a field "Name" in it can be referred to as "A.Name", while object "A" probably has a property "Name" that could be referred to as "A.Name". VFP prefers the Table reference over the memory variable reference. One way to remove this obfuscation is to qualify the object variable as a memory variable: "M.A.Name"

This can also often happen with unqualified references to memory variables in utility functions: if a utility function, say "GetToken" is called when the current table has a field in it "Length", then inside the function is something like:
Code: 
FUNCTION GetToken
PARAMETER InString
LOCAL Length
....
Length = Len(InString)
FOR I = 1 to Length
 ....
ENDFOR
....
Then, the for loop will NOT execute from 1 to the length of InString, but will instead execute from 1 to whatever is stored in field "Length" in the currently selected alias.

It is best to qualify every memory variable (though most of us are too lazy to do so) and AT LEAST use a prefix that identifies the variables type (which, in most cases, sufficiently differentiates the variable from any table field, as in "lcName" as opposed to "Name", but sometimes it isn't sufficient, as in "loCust" and "Locust")

A better way to code "GetToken", with all the wonders of VFP's improvements, is similar to the following:
Code: 
FUNCTION GetToken( lcInString )
LOCAL lnLength
....
m.lnLength = Len(m.lcInString)
FOR I = 1 to m.lnLength
 ....
ENDFOR
....
Register to add this FAQ to your archive
Register to rate this FAQ  : BAD 1 2 3 4 5 6 7 8 9 10 GOOD
Please Note: 1 is Bad, 10 is Good :-)

Part and Inventory Search

Back
Top