Parent/Child Relationships Revisited
No, this isn't about how to deal with your daughters first date, or what to do if your son breaks curfew, but instead is a different way of connecting input processes together. Normally, if we have a parent process with some optional children, the user has to return to the parent from one optional child before they can run a different optional child. This page discusses a simple technique whereby the user can go directly from one optional child to another, without having to return to the parent each time.
The new PASS and RECEIVE commands can be used in more places than just before a GOSUB command, you can also execute PASS commands before invoking an automatic or optional child, and execute the corresponding RECEIVEs in the Start of Process event point. This works well, but there is a subtle problem that you can encounter if you put your PASS commands in the Pre-Invocation point of the automatic/optional child. This Event Point is actually executed multiple times, as many as three times if the child process has a PCF and Auto Update is turned on. Briefly, the three phases are:
Phase I - Discovery - APPX needs to know if any of the children attached to the frame are going to run in order to decide whether to update the PCF file or not. It runs the Pre Invocation code for *each* child (if there's more than one), and checks the INCLUDE CHILDREN flag to see if the child will run. If there is at least one child that's going to run, then APPX updates the PCF record, and continues to Phase II.
Phase II - Referential Integrity - Since the parent PCF was updated, APPX has to allow for the possibility that the record key was changed, and it may have to update the keys on the child records. It runs thru the Pre-Invocation of each child again, and for every child where the auto update flag is on, runs the Post PCF Read, Pre PCF Update and Post PCF Update Event Points.
Phase III - Invocation - Now APPX is ready to actually run the child processes. The Pre Invocation step of each child is run to determine if that particular child should run or not.
The end result of all this is that you may execute the PASS command several times, but only RECEIVE them once. The 'unused' fields that were PASSed are still on the stack, and the next process that does a RECEIVE will pick up the leftover PASSed fields, not the ones that you probably intended. How do you deal with this? Put the following code in the child, after you have RECEIVEd everything you expect:
BEG LOOP WI = 000 to 001 STEP 000 RECEIVE --- TEMP 80 T END LOOP WIThis will 'use up' the extra PASS commands. If you prefer you can put this in a subroutine, and use it where required. In that case, do not GOSUB to the routine, use COPY instead.
--- PRINT SUMMARY ONLY
This flag is used to control whether or not APPX should print the detail record frames on an output. Normally, this flag is set by the 'Print Summary Only' flag on the Disposition screen and it applies to the entire report. However, it's possible to change this flag in a RANGE-START frame and APPX will respect the new setting for the next group of records. This means that, via ILF, it is possible to print details for some ranges and totals only for other ranges.
Using PUSH/POP to automate keystrokes
ASI has introduced the PUSH and POP ILF statements. These can be used to save and restore multiple values for a field or record (unlike STORE/ RESTORE which only store one value). When used with the --- OPTION field, PUSH gives us a way to 'feed' keystrokes into an INPUT process. For example, let's say we wanted the input process to automatically invoke Option 7, followed by a Return. Before invoking the process, we do the following:
SET --- OPTION = USER 7 PUSH --- OPTION SET --- OPTION = RETURN PUSH --- OPTIONIn the Pre-Display of the input process, we just add a 'POP --- OPTION' statement. The first time this EP is executed, it will set --- OPTION to USER 7, the next time it will set --- OPTION to RETURN and the third time it will do nothing since there's nothing left on the stack to POP. At that point, the input process will display the image to the user & wait for input from them. What if you also want set a value in a field, as well as set --- OPTION? One technique would be to PUSH a unique value into --- OPTION (e.g., USER 200), PUSH the value into the field and then later test for the unique value:
SET --- OPTION = USER 200 PUSH --- OPTION SET DMO WORK CUSTOMER NO = 130123 PUSH DMO WORK CUSTOMER NOThen in Pre-Display:
POP --- OPTION FIELD T IF --- OPTION EQ USER 200 TT POP DMO WORK CUSTOMER NO FIELD TT SET --- OPTION = RETURNPOP returns a T indicator if there is something on the stack to retrieve. If there is, and it is our special value, then we know to also POP the WORK CUSTOMER NO field to set its value and then set OPTION to RETURN so the process will continue automatically. Although PUSH/POP will officially be part of 4.3, they are included and functional in 4.2.9.
For additional information, contact firstname.lastname@example.org
[back to top]