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.