Release 10.1A: OpenEdge Development:
Progress Dynamics Advanced Development

> ## Defining logic in a single custom super procedure

> The first example is for a window managing the `Customer` table using the customerfullo SDO. The examples use objects from other parts of the documentation. If you need some of the base objects, you can simply build them. If your objects have different names, just adjust accordingly.

> Suppose you want to define a user interface condition so that if the customer’s credit limit does not exceed the balance by at least $5,000, the Balance field is highlighted to show this. This check must be made whenever a row of data is displayed in the viewer, and also when the Credit Limit or Balance field is modified.

> In a static viewer, you could simply write a simple statement into a local override of the `displayFields` procedure, which is executed each time a row is displayed, as shown:

>     PROCEDURE displayFields:
>     /*-------------------------------------------------------------------------
>       Purpose:     Super Override of displayFields
>       Parameters:  pcColValues AS CHARACTER
>       Notes:       Highlights the Balance if it's too close to CreditLimit.
>     -------------------------------------------------------------------------*/
>       DEFINE INPUT PARAMETER pcColValues AS CHARACTER NO-UNDO.
>       RUN SUPER( INPUT pcColValues).
>       DO WITH FRAME {&FRAME-NAME}:
>         IF DECIMAL(RowObject.CreditLimit:SCREEN-VALUE) -
>            DECIMAL(RowObject.Balance:SCREEN-VALUE) < 5000.00 THEN
>              RowObject.Balance:BGCOLOR = 14.  /* Highlight the field in yellow. */
>       END.
>     END PROCEDURE.

> Note that there are some complications to writing code like this, because the viewer does not actually have access to the database record, or even the `RowObject` temp-table record. Because it is strictly a thin client object, the field values are simply copied into the screen values of the fields on display, and copied from there back to the associated SDO on save. So your code must use the `SCREEN-VALUE` attribute of each field to get at its value and then convert it to the proper data type. Also, note how the code scopes the field references to the default viewer frame name, which is represented by the preprocessor `&FRAME-NAME`.

> If you want this same code to be executed `ON` `LEAVE` `OF` the `Balance` and `CreditLimit` fields, you can define a UI trigger for those events in the AppBuilder and associate the same code with them. In that case, it makes sense to move the code itself into a separate procedure to call from both places.

> This kind of code is not available to a dynamic Viewer because there is no place to write the code. So you have to move the code to a custom super procedure you associate with the Viewer instance. In this case, the fields such as `RowObject.CreditLimit` are not directly available to the compiler when it compiles your super procedure, so you cannot reference them. Instead, your code must access the fields with the client API, which again is an instance (a running copy) of the single procedure rydynviewv.w, which reads data for your specific Viewer out of the Progress Dynamics Repository and creates the Viewer for you at run time.

Copyright © 2005 Progress Software Corporation www.progress.com Voice: (781) 280-4000 Fax: (781) 280-4095