Consultor Eletrônico

Status: Unverified

GOAL:

ADM. How to reposition the query of a SmartObject such as a SmartQuery

FACT(s) (Environment):

Progress 8.x

FIX:

The Progress ADM1 architecture defines a procedure named reposition-query.  It allows SmartObjects that contain data to reposition their own queries.  

The reposition-query ADM1 procedure is placed into the code of record.i, a standard ADM1 include file which is inherited by both SmartQuery and SmartBrowser objects.  When you make a call to the reposition-query ADM1 procedure, you must pass an input parameter to it, that is, the handle of the SmartObject (for example, a SmartViewer) that wants the query of the SmartQuery or SmartBrowser object to be repositioned.  Once you do that, then the ADM1 structural design will internally make a call to another ADM1 procedure in the SmartObject whose handle was passed to the reposition-query ADM1 procedure.  This is in order to get the ROWID of the record that the query of a SmartBrowser or a SmartQuery object should be repositioned to.  The procedure that's internally executed is the get-rowid ADM1 procedure.  The get-rowid procedure resides in the code of another standard ADM1 include file called tableio.i.  That ADM1 procedure defines an output parameter as ROWID, which is in turn, eventually assigned to the adm-first-table ADM1 variable.

This information shows that if we have a record available in the buffer pool of a particular SmartObject context, we can assign its ROWID to the adm-first-table ADM1 variable.  This also demonstrates that the reposition-query ADM1 procedure can receive that desired record's ROWID and will consequently be able to reposition the query to that record.

For example:  Consider that we have a SmartObject Application which runs against the Progress sports database.  It contains a customer SmartBrowser, a customer SmartViewer, and a standard SmartPanel in save mode; all instantiated to a SmartWindow.  The customer SmartViewer has a customer number fill-in (cust-num) as one of the displayed fields.  As soon as the user types in a customer number and hits the enter key or leaves the cust-num fill-in, your application code should make sure that there is not already an existing customer with the same number before allowing the user to save the current record.  If there is an existing customer with that same number, then the customer SmartBrowser query should be repositioned to that existing customer's record.  The code behind the LEAVE or RETURN trigger for the cust-num fill-in should look like this:

DEFINE VARIABLE vcObjHdl AS CHARACTER NO-UNDO.

DO WITH FRAME {&FRAME-NAME}:
FIND Customer NO-LOCK WHERE Customer.cust-num = INTEGER(cust-num:SCREEN-VALUE) NO-ERROR.

IF AVAILABLE(Customer) THEN
DO:
 ASSIGN adm-first-table = ROWID(Customer).
 RUN dispatch IN THIS-PROCEDURE ('CANCEL-RECORD').
 RUN get-link-handle IN adm-broker-hdl (THIS-PROCEDURE, 'RECORD-SOURCE', OUTPUT vcObjHdl).
IF NUM-ENTRIES(vcObjHdl) = 1 AND VALID-HANDLE(WIDGET-HANDLE(ENTRY(1,vcObjHdl))) THEN
DO:
RUN reposition-query IN WIDGET-HANDLE(vcObjHdl) (THIS-PROCEDURE).
   RUN dispatch IN THIS-PROCEDURE ('ROW-AVAILABLE').
END.
END.
END.

NOTE: If you are trying to reposition the query of a SmartQuery or a SmartBrowser object from the code of a SmartObject that does not inherit the tableio.i standard ADM1 include file (for example, a SmartWindow), then you must manually create an internal procedure to that SmartObject named get-rowid.

For example

DEFINE VARIABLE vrCustRowid AS ROWID NO-UNDO.

/* In this case, the local vrCustRowid variable is used */
/* instead of using the adm-first-table ADM1 variable,  */
/* which is not defined for a SmartWindow.              */

ASSIGN vrCustRowid = ROWID(Customer).

PROCEDURE get-rowid:
DEFINE OUTPUT PARAMETER prCustRowid AS ROWID NO-UNDO.

 ASSIGN prCustRowid .= vrCustRowid.
END PROCEDURE.
.