All objects should be accessed in one of the following ways:
Send|Get|Set Message [of self]
This sends the message to itself (sending and receiving object are the same). The of self is not necessary. The compiler will do this for you. Most messages are sent within an object. You will use this method most-often.
Delegate Send|Get|Set Message
This sends the message to the object's parent.
Send|Get|Set Message of object_name
This will find an object_id for the access expression and send a message to it. When required, the access method is delegated.
Move object_name to hoId
Send|Get|Set Message of hoId
If you are sending multiple messages to an object inside a function or procedure, you can save some time if you evaluate the object_id once and send all messages to this Id (hoId). This saves the runtime from having to continually re-evaluate the same expression. The speed difference is going to be quite small. If a message is sent to an object only one time in a function or procedure, use the previous access method. If multiple messages are sent to an object, use this method.
For example:
Procedure doSomething
Handle hoID
Move oMyObj to hoID
Send request_save of hoID
Send request_Clear of hoID
Send Activate of hoID
End_Procedure
You can use these access rules as a means of confirming that your program is properly encapsulated. If you cannot access an object using one of these methods, you should not be accessing that object.
The question that usually arises at this point is, "How do I send a message to a grandchild object?" The answer is, "Normally, You don't"! (The exception is discussed in the next paragraph.) If you need to access a grandchild object, you should send a message to the child object, which should then send a message to its child. If you insist on breaking this rule, you may do so with an expression (e.g., Send Message of (oGrandChildName(oChildName)) ). Treat this kind of code the same way you would a goto statement. Place several comments around it stating that you know this is wrong, apologizing for it, and promising to come back and correct it. If you are maintaining someone else's code and you encounter this kind of code, proceed cautiously.
There is a very useful exception to this rule. When building visual applications visual objects are often nested inside of other visual container objects. When this type of object nesting occurs, it is done to make a panel or dialog look right and it is not done for purposes of encapsulation. When these visual objects need to communicate with each other access can be complicated. Object Neighborhoods are used to remove this complication.