Try OpenEdge Now
skip to main content
ProDataSets
Advanced Events and Attributes : Successive loading of ProDataSet data
 

Successive loading of ProDataSet data

The following procedure updates your code, so that you can do an initial load of header information into a ProDataSet, let the user make a selection from those header rows, and then fill in detail for selected rows.
To update your code:
1. To get started, copy the final version of dsOrderWinUpd.w from Updating Data with ProDataSets to a new procedure called PickOrder.w.
2. Delete the Order temp-table fill-ins from the window.
3. Define a browse for ttOrder with the columns OrderNum, CustNum, SalesRep, and OrderDate. Name the new browse OrderBrowse.
Remember that you can do this in the AppBuilder by selecting the Temp-Tables dummy database in the query builder for the browse. Since you copied the procedure from the earlier one, it has all the same temp-table definitions.
4. Define new fill-ins called iCustNum, daOrderDate, and cSalesRep.
5. Make the initial value of daOrderDate blank (using the Unknown value (?)) so that it does not display today's date by default.
An easy way to get the fill-ins to inherit the attributes of the fields they represent in ttOrder is to go through these steps for each one.
6. Select the fill-in from the Palette and drop it onto the design window.
7. Double-click on the fill-in to bring up its property sheet. Choose the Database Field button:
8. From the Field Selector dialog box, select the field from the Temp-Tables database and ttOrder table, as shown:
9. Make the field's Control TypeLocal Variable, as shown:
10. Set the Object name in the property sheet to the variable name, such as iCustNum.
This creates a local variable definition with the same attributes for label, format, and so forth as the temp-table field, but does not actually define the fill-in as the temp-table field. This is because you will not use these fill-ins to display fields from the current ttOrder, but rather to enter filter criteria for retrieving Orders through the ProDataSet.
You will use these fill-ins to allow the user to filter Orders by entering a value into one or more of the fields. The window procedure will request a dsOrder ProDataSet with all the Orders that satisfy the selection, and then allow the user to select an Order and fetch OrderLine detail for it.
11. Remove all the commented-out code from the CHOOSE trigger for BtnSave. Change the statement at the end that re-enabled iOrderNum (which is no longer there) to re-enable the three filter fields after a Save has been processed, as shown:
/* Re-enable the filter fields to select another set of Orders. Also, set
   TRACKING-CHANGES back to TRUE to capture any further changes made to
   this Order. */
ASSIGN
  iCustNum:SENSITIVE IN FRAME dsFrame    = TRUE
  daOrderDate:SENSITIVE IN FRAME dsFrame = TRUE
  cSalesRep:SENSITIVE IN FRAME dsFrame   = TRUE
  SELF:SENSITIVE                         = FALSE
  TEMP-TABLE ttOline:TRACKING-CHANGES    = TRUE.
12. Change the ROW-LEAVE trigger code for the OlineBrowse to change the reference to iOrderNum to disable the three filter fields, in the same way as in Step 11:
IF OlineBrowse:MODIFIED THEN
  ASSIGN
    INPUT BROWSE OlineBrowse
    {&ENABLED-FIELDS-IN-QUERY-OlineBrowse}
    /* Disable the Order Number until changes are saved. */
     iCustNum:SENSITIVE IN FRAME dsFrame    = FALSE
     daOrderDate:SENSITIVE IN FRAME dsFrame = FALSE
     cSalesRep:SENSITIVE IN FRAME dsFrame   = FALSE
    BtnSave:SENSITIVE IN FRAME dsFrame     = TRUE.
At this point the window should look something like this:
Now you are ready to start writing the support logic to retrieve data into the window.
13. In the Definitions section, define a handle to hold the procedure handle of the procedure that contains the event logic and other support procedures for the data retrieval. For example:
DEFINE VARIABLE hOrderProc AS HANDLE NO-UNDO.
14. In the Main Block, add a statement to kill this procedure when the window exits. For example:
ON CLOSE OF THIS-PROCEDURE DO:
  DELETE PROCEDURE hOrderProc.
  RUN disable_UI.
END.
15. Add a statement to start the procedure when the window starts up. For example:
MAIN-BLOCK:
DO ON ERROR   UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK
ON END-KEY UNDO MAIN-BLOCK, LEAVE MAIN-BLOCK:
RUN enable_UI.
RUN orderSupport.p PERSISTENT SET hOrderProc.
  . . .
The support procedure can be based on the procedure OrderEvents.p that you created earlier.
16. Copy OrderEvents.p to OrderSupport.p.
17. Remove the INPUT parameter definitions from OrderSupport.p.
18. Add variable definitions for a ProDataSet handle and a string to hold selection criteria. For example:
DEFINE VARIABLE cSelection AS CHARACTER NO-UNDO.
DEFINE VARIABLE hBuff AS HANDLE    NO-UNDO.
DEFINE VARIABLE hDataSet AS HANDLE    NO-UNDO.
DEFINE VARIABLE iBuff AS INTEGER   NO-UNDO.
19. Set the handle variable to the dsOrder ProDataSet handle and change the SET-CALLBACK-PROCEDURE references to the old input parameter phDataSet to be hDataSet, as shown:
hDataSet = DATASET dsOrder:HANDLE.
hDataSet:SET-CALLBACK-PROCEDURE
  ("BEFORE-FILL", "preDataSetFill", THIS-PROCEDURE).
. . .
* Doing a partial ProDataSet FILL to return Order headers
* Forcing the ProDataSet to be passed BY-VALUE
* Filtering the top-level query based on the user selection
* Returning the partial ProDataSet to the client
* Retrieving detail for the ProDataSet
* COPY-DATASET and COPY-TEMP-TABLE methods
* Using COPY-DATASET with a dynamic target ProDataSet
* Using the COPY-DATASET method for successive FILLs