Working with inherited objects

This section describes:

  • Working in a descendant object

  • Working in an ancestor object

  • Resetting properties in a descendant

Working in a descendant object

You can change descendant objects to meet specialized needs. For example, you can:

  • Change properties of the descendant object

  • Change properties of inherited controls in the object

  • Add controls to a descendant window or user object

  • Add menu items to a menu

You cannot copy a control on a descendant window or visual user object if the control inherits from the ancestor object, because the resulting inheritance hierarchy cannot be maintained consistently. You can copy a control on a descendant object if the control does not inherit from the object's ancestor.

For specifics about what you can do in inherited windows, user objects, and menus, see Working with Windows, Working with User Objects, and Working with Menus and Toolbars.

Working in an ancestor object

When you use inheritance to build an object, the descendant is dependent on the definition of the ancestor. Therefore you should not delete the ancestor without deleting the descendants. You should also be careful when you change the definition of an ancestor object. You may want to regenerate descendant objects if you do any of the following:

  • Delete or change the name of an instance variable in the ancestor

  • Modify a user-defined function in the ancestor

  • Delete a user event in an ancestor

  • Rename or delete a control in an ancestor

When you regenerate the descendants, the compiler will flag any references it cannot resolve so you can fix them. For information about regenerating objects, see Working with Libraries.

About local changes

If you change a property in an ancestor object, the property also changes in all descendants—if you have not already changed that property in a descendant, in which case the property in the descendant stays the same. In other words, local changes always override inherited properties.