1)GOTCHAS If you are deleting records using a partial key as a positioner, (RTVOBJ with DLTOBJ when record is found)

after the first record is found, the element number of the array is used to determine which record to process. However DLTOBJ re-sorts the array and the element number is no longer correct for the next occurrence in the array. The program still compares the partial keys to make certain that only records with a match on the partial key are processed, but some records are skipped. This bug has been reported to Synon. If you need to do this, call the RTVOBJ in a loop until there is no record found. To clear the entire array, Create a DLTOBJ with no parameters and the array is cleared with 1 move. If you ever try to change the key values for an array record, (you would have to put code inside of the CHGOBJ to do this) the array is not sorted and the index no longer works. The array is never sorted for a CHGOBJ because Synon assumes that you will never change a key. You must delete the record and add the new record.
2) I would suggest you create a simple "Prompt Record" function. You can change this to be a window by selecting the appropriate header/footer. All this function needs is a message about confirming the deletion - e.g. "Press Enter to delete selected record, press F3 to exit without deleting" and a returned parameter to say whether F3 was pressed. When delete is requested in the main program, first call your new function and only delete if the returned parameter says that deletion was confirmed. 3) created Confirm Prompt record with function type "Prompt & validate record". Why Prompt need Accepath?, How to avoid this. is not possible to create simple Prompt to say "Yes' or "No" 4) You must specify an access path. This will put some fields on the screen. However, you can drop the fields and the function won't actually read the file. You can add your own function field that has a simple Y/N value. Although it is based over the file, this is no more than where the function is stored. In our models we have a dummy file called "general functions" which just has a single dummy field and is not actually compiled. We use this for general purpose functions, such as a calendar prompt, and also commonly used windows such as confirm prompts and warning message (it may well be posssible to have a

single warning window that will serve several functions by passing the message text as a parameter), and various bits of user source. This would be a suitable function to put here to called from anywhere in the system.

5)Program Flow and User Points OK, I finished the Synon classes and have gone through the "Horse Racing Model" and I'm ready to build my first programs. The second question is what do I want to tell it to do and where do I put the code. The first question is what function type should I pick. If there is no one with experience to suggest a function type and talk about the trade-offs of using EDTFIL or DSPFIL, or EDTRCD, or ..., I just have to pick one and start out. I am willing to change my mind at any time when I decide that I could have made a better choice. I am ignoring the questions about my intelligence and sanity which always crop up when I start something new. This article addresses the issue of which user points to select and why. An EDTFIL is used for the example, but at a conceptual level the program flow for most of the functions is similar. A DSPFIL is like an EDTFIL except that there are no updates. An EDTRCD is like an EDTFIL except that there is only 1 record in the subfile, and there is no subfile control. Try to think of the program as 1 big loop which contains 3 smaller loops. The Big Loop Do While (Not End of Program) Load screen contains loop 1. * The Screen is Displayed. Validate screen contains loop 2.. * The Confirm Prompt is Displayed. Update records contains loop 3. ENDDO The 3 Smaller Loops loop1 Load screen 1A) Initialize Subfile Control Do While (NOT End of File AND NOT Page is Full) 1B. Subfile Record Function fields 1C. Initialize Subfile Records. ENDDO 1D) The Screen is Displayed (and waits for user to take some action) loop2 Validate screen 2A) Subfile Control Function fields 2B) Validate Subfile Control Do While (More Changed Records) 2C. Validate Subfile Record fields. 2D. Subfile Record Function fields. 2E. Validate Subfile Record Relations. ENDDO 2F) The Confirm Prompt is Displayed (and waits for user to take some action) loop3 Update records Do While (More Changed Records) 3A) Update Subfile Records : (Add/Change/Delete) 3B) Process Subfile Records after update. ENDDO 3C) Process Command Keys *** The question to keep asking is "What am I really trying to do?" *** Load screen If you are trying to display information so that the user can make a decision, or If you are concerned about gathering and formatting data for a screen, the code belongs in the "LOAD" portion of the program. If it is one time only, then it goes

in 1A) Initialize Subfile Control . If it needs to be executed for every record then the code belongs in 1C) Initialize Subfile Records. Validate screen If you want to edit information that the user has entered or requested, or call programs to display information, the code goes in "VALIDATE". Same as above. If it's one time use 2B) Validate Subfile Control . If is for one or more subfile records, use 2C) Validate Subfile Record fields. Another question to ask is "Do I want to take this action before or after the file(s) are updated?". If the answer is after the updates, the code should be in the "Update" section. Do Not put file updates in the validate part of the program (there are a few exceptions). Update code belongs in the "UPDATE" section Update records Same as above. "Do I want one or many?" If it is one, use 3C) Process Command Keys . If many, I would probably use 3B) Process Subfile Records after update. These are conceptual guidelines. Try to think conceptually and not get bogged down in the code. Try things out just to see what will happen. CONTROL of the Program Flow "PGM.Reload Subfile" gives you the ability to re-initialize the screen from the file, (GOTO 1A) "PGM.Defer Confirm" gives you the ability to re-display the screen without re-loading the subfile from the file, (GOTO 1D). Let's look at the validate portion of this process again. Validate screen 2A) Subfile Control Function fields 2B) Validate Subfile Control IF PGM.Reload Subfile = YES, GOTO 1A Do While (More Changed Records) 2C. Validate Subfile Record fields. 2D. Subfile Record Function fields. 2E. Validate Subfile Record Relations. ENDDO IF there are errors, error messages are sent. IF PGM.Defer Confirm = "Yes", ELSE The Confirm Prompt is Displayed. GOTO 1D GOTO 1D 2F) The Confirm Prompt is Displayed (and waits for user to take some action) IF the user enters "N" at the Confirm Prompt, IF the user presses "Y", GOTO 1D Continue at 3A. (IF the Confirm Prompt has been turned off, Confirm Prompt = "Y". The program does not stop at 2F and the confirm prompt is not displayed.) "Reload Subfile" placed in Validate Subfile Control will GOTO 1A after the instructions in Validate Subfile Control are completed (after 2B). This allows you to test values (including non-key values) in the subfile control and reload the screen from the file. "Reload Subfile" placed in Validate Subfile Records MAY GOTO 1A after the validations for all changed subfile records have been completed. (after 2E). "Reload Subfile" is ignored

and the program continues with update processing unless something prevents update processing. (IF PGM.Defer confirm is "Yes", OR IF the user keys "N" at the confirm prompt, OR IF there is an error). The error processing may result in a "gotcha" and overlay the error corrections. "Defer Confirm" placed in Validate Subfile Records will GOTO 1D after the validations for all changed subfile records have been completed (after 2E). The screen will be re-displayed and will wait for the user to take some action. NOTE: Defer Confirm has the same effect as the user keying "N" at the Confirm Prompt. Defer Confirm acts almost like an error message without the message. Random Information: *** Initialize: This user point is the first thing processed when the program begins, before 1A. It is executed one time only for the life of the program. *** IF F3 is pressed, the program skips all user points except "EXIT Processing". Then the program goes to the end and returns control to whatever called it. *** When a record is marked for "Deletion", no validations are performed for that record. Skip 2C, 2D, and 2E. (do you really want to be required to enter a valid Customer# for a record that you just want to delete ? Synon assumes not.). *** 1B) Initialize Subfile Record The screen is only loaded one page at a time, so records which would fall on page 2 would not be processed until "Page Down" is pressed. Records which are omitted from the access path would not be processed. etc. EDTTRN is an exception. It loads every record in the file and updates every record in the file when enter is pressed. EDTTRN is not processed in a loop but goes to end of program after updating ALL records. EDTTRN's are junk and should be avoided. *** Although the user point for Subfile Record Function fields exists in only 1 place, it is executed in 2 places, 1B and 2D. *** 2E) Validate subfile relations happens after the file relations (Owned by, Refers to) are checked. The virtual fields are available for this user point. *** After the 3A, 3B loop and before 3C, IF the EDTFIL is in ADD Mode, OR IF any records were deleted, "Reload Subfile" is set to "YES". ELSE the EDTFIL is in CHANGE Mode, "Reload Subfile" is still "NO" (it is NOT re-set) ENDIF Use 3C) Process Command keys to force a re-load or change program modes. IF PGM.Reload Subfile is "Yes",

ELSE GOTO 1A GOTO 1D.

6) 2e Development Standards - Screen Functions (Part III)

Posted by Lee Dare at 11:43 Today we shall take a quick look at the Display File function (DSPFIL). This is a very commonly used function type in 2e and if my notes are correct there may be a thing or two of interest in this post. However, I guess that this depends on whether you are an ageing old developer like myself or one of the new kids on the block in Bangalore. But back to the action. Like many other function types the DSPFIL can be used to display data and interact with it in multiple manners. i.e. It can act like an intelligent Select Record and also allow multiple selects. It can also be used to show the contents of an array. Hold on I hear you say. "It's a display file and arrays are not files......" That's true but there are methods to complete this. Nudge me with some comments and I might write up a few examples of code to show you how to achieve this. Also as the DSPFIL has the CTL (header region) it can be used to provide an interface with a tab look 'n' feel. Anyhow. Major tip. Take a look at the function options for this function type. In particular, the function option called Re-Process Subfile. Set this on and off and take a look at the action diagram. There will be additional user points and logic added if this is set to Yes. This is just another example of the PODA principle that is taught when you attend training. PODA stands for Parameters, Options, Design and Action Diagram. The philosphy behind this is simple. The more correct decisions you make at the preceding level i.e. Paramters first, then options (function options) etc the less coding (action diagramming) you will need to do. 2e is quite a neat tool. You should be judging your developers based on the least amount of code required rather than rewarding on a LOC principal (Lines of Code). I think it is fair to say that anyone can write a bad program. Below are two sections that provide some insight into the function. General Considerations The default scan limit is 500. This may not be appropriate for large files. If necessary set the scan limit in USER:Initialise Program to a higher value or even to Maximum. Note:

That the scan limit is a model value. If you require a higher number by default (across your model) then I recommend you change the model value YSCNLMT. Best Practice Any subfile control selector fields not used should be dropped rather than hidden. This is for performance reasons and avoids the problem of unintentionally deselecting subfile records. To do this simply place enter - against the field from within the EDIT SCREEN FORMAT DETAILS screen. Multi-part ACP key fields acting as positioners will automatically become selectors if low order fields have data and high order fields are blank. Ensure that you understand the type of data likely to be used for the screen. Check that the operators used by subfile selectors are appropriate for the function design. Ensure you want EQ, LE, GT or CT for example. Don't assume the default role of these fields. If a positioner or selector field has mod 10/11 check digit then it may be appropriate to replace with a function field without the check digit. The user does have to enter a valid number to position within a list. Tip There is no standard feature to stop the function loading records into the subfile under programmer control. The program continues until subfile page full, scan limit reached or hits end of file. However, you may trick the function to thinking its hit end of file by using a RTVOBJ over the same ACP using a very high key value. This positions the file cursor at end of file. USER:Process Command Keys has got nothing to do with command keys. Command key processing should normally be added to USER:Process Subfile Control. Subfile select status field is automatically set to blanks if subfile record processing completes without error. Gotchas If F4=Prompt is used on any subfile control selector STS type field then there is no automatic subfile reload and CALC:Subfile Control Function Fields is not executed. User then has to press enter to invoke appropriate selection logic. Function works OK if '?' is used. There is no known workaround for this bug. I would suggest that this is not actually a bug and it is harsh to judge it that way. It is simply because the enter key was pressed for the ? and not the F4 prompt. CALC:Subfile Record Function Fields is executed before USER:Initialise Subfile Record

and therefore you may process a record subsequently deselected. i.e. PGM.*Record Selected. If any RST input parameter key is also input on device design, and its a file to file relation, then that file validation is deferred until the main validation cycle rather than take place during the load cycle. Any automatic virtuals from the 'Owned by' file will be blank when function is loaded. An input function field added to RCD format will not automatically check for required value. Even if you set the value to Allow Blank . This is because the DSPFIL template isnt designed to have input fields and doesnt generate the validation routine regardless of how the flag is set or any check conditions. Need to add the code procedurally via the action diagram to force input. An input function field added to CTL format will not automatically check for required Value. Need to add the check procedurally. Thanks for reading. Lee. 7)