Release 10.1A: OpenEdge Development:
ProDataSets

> ## Changing the window procedure to use the new procedures

> You can test these new procedures with a window procedure very much like `dsOrderWinUpd.w`.

> | To update the code:

> 1. Copy `dsOrderWinUpd.w` to `dsOrderWinAdv.w` (`adv` for “advanced”).

> 2. Add this new Definition to it. This is the handle of the `Order` entity. This is now a persistent procedure, rather than running `OrderSupport.p` as a standalone `.p`:

>     DEFINE VARIABLE hOrderSupport AS HANDLE     NO-UNDO.

> 3. Change the Main Block to run `OrderEntity.p` as a persistent procedure:

>     MAIN-BLOCK:
>     DO ON ERROR   UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK
>        ON END-KEY UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK:
>       RUN enable_UI.
>       RUN OrderEntity.p PERSISTENT SET hOrderSupport.
>       …

> 4. Change the `CLOSE` trigger in the Main Block to give the `Order` entity procedure a chance to clean up:

>     ON CLOSE OF THIS-PROCEDURE
>     DO:
>        APPLY "CLOSE" TO hOrderSupport.
>        RUN disable_UI.
>     END.

> 5. In the `LEAVE` trigger for `iOrderNum`, change the run of `OrderMain.p` to run `fetchOrder` in the `Order` entity procedure:

>     TEMP-TABLE ttOline:TRACKING-CHANGES = FALSE.
>     DATASET dsOrder:GET-RELATION(1):QUERY:QUERY-CLOSE().
>     DATASET dsOrder:GET-RELATION(2):QUERY:QUERY-CLOSE().
>     DATASET dsOrder:EMPTY-DATASET.
>     RUN fetchOrder IN hOrderSupport
>         (INPUT iOrderNum, OUTPUT DATASET dsOrder).

> Note that the `OUTPUT` `DATASET` `dsOrder` parameter is not passed `BY-REFERENCE`, and should not be. If `OrderEntity.p` were running in a separate session, it would be ignored and would make no difference. But when it is running in the same session, you want the ProDataSet that is initialized, attached, and returned by `fetchOrder` to be the one the client uses, not the client’s locally defined ProDataSet, which is not attached to any Data-Sources.

> 6. In the `CHOOSE` trigger for `BtnSave`, remove the code that is now in `clientChanges.p` so that the trigger is reduced to this:

>     DO:
>       DEFINE VARIABLE hDSOrder   AS HANDLE     NO-UNDO.
>       TEMP-TABLE ttOline:TRACKING-CHANGES = FALSE.
>       cStatus = "".
>       hDSOrder = DATASET dsOrder:HANDLE.

>       RUN clientChanges.p
>           (INPUT hDSOrder, INPUT hOrderSupport, OUTPUT cStatus).

>       DISPLAY cStatus WITH FRAME dsFrame.
>        /* END of Error status checking. */
>        /* Re-enable the Order Number to select another Order.
>           Also, set TRACKING-CHANGES back to TRUE to capture
>           any further changes made to this Order. */
>        ASSIGN iOrderNum:SENSITIVE IN FRAME dsFrame = TRUE
>               SELF:SENSITIVE = FALSE
>               TEMP-TABLE ttOline:TRACKING-CHANGES = TRUE.
>     END.

> You can see how much of what this trigger does has been replaced by the generic support procedure `clientChanges.p`.

> That’s it. If you save this and run it, it should work exactly as it did before, with much less code in the client procedure and much less code in the support procedures because of `clientChanges.p` and `commitChanges.p`. Also, your `Order` support logic has been better organized into procedures that do specific parts of the job in ways that you can use as a standard for other ProDataSets.

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