CloneObject | Hackers Guide to Visual FoxPro 7.0

Name

This property is one of the keys to OOP. It's what you use to refer to an object so you can look at its properties, change them, or call a method.

Usage

oObject.Name = cName cName = oObject.Name

Every object in Visual FoxPro has a Name property, except for those created in weird ways like using SCATTER NAME.

You can assign a name to an object in the Property Sheet when you add it to another class, or in its own Init method (or the container's Init method). Although you can change the Name of an object at runtime, it's usually not a good idea once you get past the Init method. If you have code that depends on an object's Name and you change Name, the code fails.

If you don't assign an object a Name, FoxPro does it for you. That's why the first text box you add to a form is Text1 and the next is Text2, and so on. With classes defined in code (rather than a VCX), there can be a tremendous performance penalty for letting FoxPro do it in versions prior to VFP 7. See "Faster Than a Speeding Bullet."

Despite the warning above, in a code class, don't ever assign Name a value in the properties section unless it's the same as the class name. Instead, assign the new instance a Name in Init. When you do the assignment in the properties section, it changes the name of the class, not the name of instances of the class.

Although you usually use Name to refer to an object, you don't do that for the outermost object that gets created via either CREATEOBJECT() or DO FORM. For that object, use the variable holding the object reference—then, you can drill down into the object using the names of the various members.

Example

DEFINE CLASS MyTextBox AS TextBox   * Don't do this! * Name = "anything" * But do this for speed issues, if using a coded class. Name = "MyTextBox"   PROCEDURE Init   * Do it this way instead, or the class name changes. This.Name = "anything"    ENDPROC   ENDDEFINE