I4GL Modifications: Part 3 of 3

#!/bin/sh # this is part 3 of a multipart archive # do not concatenate these parts, unpack them in order with /bin/sh # file i4glmods continued # CurArch=3 if test ! -r s2_seq_.tmp then echo "Please unpack part 1 first!" exit 1; fi ( read Scheck if test "$Scheck" != $CurArch then echo "Please unpack part $Scheck next!" exit 1; else exit 0; fi ) < s2_seq_.tmp || exit 1 echo "x - Continuing file i4glmods" sed 's/^X//' << 'SHAR_EOF' >> i4glmods X the ENTRY or NOENTRY status of a field to be set, and the REQUIRED or X NOT REQUIRED status too. In fact, most of the input attributes should X be settable dynamically (see also I4GL-I01). X X I4GL-I02 was rated in class B because it would be very useful. X XI4GL-I03: X One correspondent (not from CDI) requested that it be made easier to X move from an INPUT statement to an INPUT ARRAY statement in a X master/detail type screen, the implication being that the user should X not have to hit the ACCEPT key to switch between the two. This is X largely under the programmer's control because the INPUT statement can X have INPUT WRAP turned off and a function key can be trapped by ON KEY X clauses to switch between the two statements. Unless someone can X clarify what is required, this is a non-request. X X I4GL-I03 was rated in class F because it is not clear that there is a X requirement. X XI4GL-I04: X The I4GL help facility always takes over the entire screen when the X user invokes it. It would often be useful if the help facility could X be programmed so that the information appeared in a window instead of X taking over the whole screen. A suitable syntax might be: X X COMMAND "Command" X "Explanation" X HELP 34 IN WINDOW w_winname X X COMMAND "Command" X "Explanation" X HELP 34 IN WINDOW AT x, y WITH r ROWS, c COLUMNS BORDER X X The first variant would use the currently open (but not current) window X w_winname to display the help message. The second would create an X anonymous window simply to display the help message. However, if this X was extended to a complete 6-option menu, the same information would X have to be written too many times. Thus, it should be possible to add X a clause to the MENU statement itself. X X MENU "Menuname" HELP 34 IN WINDOW AT x, y WITH r ROWS, c COLUMNS BORDER X X The INPUT, INPUT ARRAY and DISPLAY ARRAY statements do not have this X problem; their help is written once. But SHOWHELP needs to be aware of X the current help window so field-level help will appear in the same X window as the general help. X X I4GL-I04 was rated in class D because it would not be particularly easy X to implement. X XI4GL-I05: X It should be possible to determine the current value of any OPTION. X The result should be able to be used to reset the OPTION later (see X I4GL-L28). This allows library code to change an option to its own X value and then restore the value to what it was when the function was X called. (You should look at a graphics library such as GKS; speaking X from memory, about 50% of the functions are queries, 40% are attribute X setting, and the other 10% or so do the real work.) X X I4GL-I05 was rated in class C but it should have been done long ago. X XI4GL-I06: X A suggestion received from Adrian Flynn (adrianf@informix.com) was: X Include an AFTER UPDATE attribute on fields which executes if (a) the X cursor moves into a blank field enters a value and moves out of the X field leaving a value in the field, or (b) the cursor moves into a X field containing a value and leaves the field having changed the X original value. Do not behave like field_touched() which is true even X if the user types the original value again. You must still check to X determine whether the field actually changed. Execute AFTER UPDATE X before AFTER FIELD. X X Adding a whole new set of clauses to an INPUT or INPUT ARRAY statement X is probably not a good idea, but providing a function field_changed() X which does the job which field_touched() does half-heartedly would be X better, and could be added without any major problems. It would be X used in the AFTER FIELD clause, and would only tell you if the value in X the field had changed from the value which was current when the cursor X entered the field. If the user moved out of fieldA into fieldB having X changed the value in fieldA, then field_changed() would be true in X AFTER FIELD FieldA, but if the user moved the cursor out of FieldB back X into FieldA, and then moved back out of FieldA to FieldB again without X changing the value in FieldA, then field_changed() would be false on X the second time through the AFTER FIELD FieldA clause. X X I4GL-I06 was rated in class C but it shouldn't be very difficult to do. X X---------------------------------------------------------------------- X XDISPLAY ARRAY X XI4GL-D01: X See discussion for I4GL-I01. X XI4GL-D02: X It should be possible for the programmer to specify which row in the X program array should be the active row when the DISPLAY ARRAY starts. X This can be achieved by setting NEXT PROGRAM ROW in the BEFORE DISPLAY X block (see I4GL-D07). X X I4GL-D02 was rated in class A because it should have been done long ago. X XI4GL-D03: X It should be possible for the programmer to specify which row in the X screen array should contain the cursor when the DISPLAY ARRAY starts. X This can be achieved by setting NEXT SCREEN ROW in the BEFORE DISPLAY X block (see I4GL-D07). X X It would be possible for the programmer to make a mistake and specify X that screen row 3 should contain program row 1, thus leaving two blank X lines at the top of the displayed array. This is not desirable, but X there are two possible ways of dealing with the trouble. One (probably X the better one) is to report an error (inconsistent values of screen X row and program row); the other is to quietly ignore the request, and X in this case, the cursor would start in screen row 1 with program row 1 X displayed in it. X X I4GL-D03 was rated in class A because it should have been done long ago. X XI4GL-D04: X It should be possible for the programmer to specify which row in the X program array should be the next active row in the DISPLAY ARRAY. This X can be achieved by setting NEXT PROGRAM ROW in an ON KEY or BEFORE ROW X or AFTER ROW (see I4GL-D08) block. This is effectively equivalent to X I4GL-D02. X X I4GL-D04 was rated in class A because it should have been done long ago. X XI4GL-D05: X It should be possible for the programmer to specify which row in the X screen array should be the next active row in the DISPLAY ARRAY. This X can be achieved by setting NEXT SCREEN ROW in an ON KEY or BEFORE ROW X or AFTER ROW (see I4GL-D08) block. This is