Method Calls versus Actions |
Since version 5.2, the default context of a method is the main container of the class currently being designed. In the previous versions, the default context of an action was the immediate object container from where it was triggered. Thus, when an action is triggered from a button within a child box, the action is applied to the child box instead of the main info window. This is no longer the case with method calls. Actions are executed on the object to which the action is attached. If the object does not support the action, then the action is executed on its parent object, and so on, until a parent object is found that supports the action. For example, if a button has the query-execute() action attached, then this action will be executed on the table object. The same holds for the action-decision() action. Method calls are executed directly on the object that represents the root of the class in which the method call is specified. This is the design-time context, and does not change if this class is subsequently inserted in another class. For example, if a button on MyWindow has the QueryExecute() method attached, this method is executed on MyWindow, also if an instance of MyWindow is embedded in another window. The same holds for the ActionDecision() method. When building decision trees, be careful when combining the action-decision() action and the ActionDecision() method. If method calls are specified on menu options, these method calls are by default executed on the main window. By using the CurrentInfoBox(), CurrentColumn(), or CurrentField() methods, you can route the context to the object that currently has focus. |