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. For example:
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:
RUN clientChanges.p (hDSOrder, hOrderSupport, OUTPUT cStatus).
DISPLAY cStatus WITH FRAME dsFrame.
/* 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 is 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.
