skip to main content
OpenEdge Development: ADM and SmartObjects
SmartObject Interactions : RUN protocol
RUN protocol
All SmartObjects can invoke the behavior of other SmartObjects in themselves by running internal procedures and invoking functions and by publishing events to which other objects subscribe.
RUN statement
Many aspects of SmartObject behavior are invoked by running internal procedures and invoking functions. Much of this behavior is implemented in super procedures that support the SmartObjects. The behavior in super procedures can be localized, and the Progress interpreter will locate and execute the correct behavior. This is possible because super procedures are initialized and added to each SmartObject as each SmartObject starts up.
For example, an application can use the addLink procedure to add a link from one SmartObject to another during execution:
RUN addLink ( hSourceProc, ’navigation’, hTargetProc ).
In this code, hSourceProc is the HANDLE of the source procedure and hTargetProc is the HANDLE of the target procedure.
The RUN statement for addLink is written as if addLink were an internal procedure within the calling procedure. In fact, it is contained in the super procedure smart.p. The super procedure mechanism makes the contents of smart.p available to every SmartObject. Standard behavior of this kind includes the following procedures (any many others):
*initializeObject — Runs when each object is started, to initialize that object
*destroyObject — Runs when an object is terminated, to destroy that object
*addMessage — Adds an error message to a message log
Similarly, the contents of other SmartObject super procedures are available to SmartObjects that require their support. For example, all visible objects use the super procedure visual.p and all SmartObjects that can contain other SmartObjects use containr.p. (See the AppBuilder online help for a detailed list of super procedures and their contents.) Using this architecture locates the majority of SmartObject behavior in a set of independently built procedures that can serve all SmartObjects that are running in a Progress session. This helps to organize behavior into reusable classes and keeps the size of individual SmartObjects to a minimum.
Just as a SmartObject can RUN procedures implemented in its super procedures, a SmartObject can invoke behavior in another SmartObject simply by knowing its procedure handle and running internal procedures or functions in that SmartObject. For example, one SmartObject can destroy another by executing the following statement:
RUN destroyObject IN hOtherObject.
Localizing standard SmartObject behavior
Another advantage of using super procedures to implement classes of behavior is that you can localize each of the internal procedures and functions that compose a super procedure in any individual SmartObject by writing a procedure or function of the same name. You can do this either to replace the standard behavior or to augment the standard behavior as required by the SmartObject. The Section Editor supports this functionality by identifying the internal procedures and functions that you can override based on the type of object you are creating.
To create a new displayFields procedure for a SmartDataViewer in the AppBuilder:
1. In the Object Palette, right‑click on the SmartDataViewer button.
2. Choose New SmartDataViewer.
3. Complete the steps in the SmartDataViewer wizard.
4. On the AppBuilder toolbar, choose the Edit code button.
5. Change the Section to Procedures.
6. Click the New button. The New Procedure dialog box appears.
7. Choose the Override Type radio button. The Name fill‑in field becomes a combo box:
8. Choose the displayFields procedure and click OK. The Section Editor generates a skeleton of the local procedure or function. This contains the necessary parameter definitions and, by default, invokes the standard behavior by executing the RUN SUPER or RUN SUPER ( ) statement:
9. You can change this code as required for your application. For example, to change the color of the fields in the SmartDataViewer, change the code as shown:
Note: This code augments the standard displayFields behavior and affects all instances created from this master.