tmm1@mtuxo.att.com (XT147-T.MORGAN) (06/23/88)
[] I am using Informix 4GL, version 1.10 and have a question regarding multi-screen forms. I have developed a single table form that has two screens. I currently developing a module that will add, update, and revmove data from the table by using the form. My problem is that the INPUT command does not like multi-screen forms. It prints both screens on the terminal at the same time resulting in a mess. Any suggestion about how to deal with this problem? Tom Morgan ATT - Lincroft, NJ mtuxo!tmm1
nobody@scubed.UUCP (anonymous NFS user) (06/25/88)
In article <2086@mtuxo.att.com> tmm1@mtuxo.att.com (XT147-T.MORGAN) writes: > >I am using Informix 4GL, version 1.10 and have a question regarding >multi-screen forms. I have developed a single table form that has >two screens. I currently developing a module that will add, update, and >revmove data from the table by using the form. My problem is that >the INPUT command does not like multi-screen forms. It prints both >screens on the terminal at the same time resulting in a mess. Any >suggestion about how to deal with this problem? Yes, it is possible to achieve multi-screen forms in Informix 4GL. As you probably know, multi-screen forms are available in Informix-SQL, however, this feature is gained at the expense of other flexibilities. In my case, I have a large number of fields which I have spread over three screens (although this could be extended to n screens). Part of the solution involves separating your individual screens into separate form files. The rest is really just slight of hand within a WHILE loop. I have implemented F1 and F2 keys (as ON KEY interrupts) to use in moving to the previous and next screens (including wrapping from the first screen to the last screen and vice-versa). LIMITATIONS: As I recall, the only problem dealt with the usage of the ON KEY interrupts. In order for a change to a field to "take" you must move from the field. This means that if you make a field change and invoke an interrupt before leaving the field, the changes (to that field) will not be remembered. This is different from Informix-SQL which somehow is capable of handling this problem. My apologies for liberties taken in comments, style and for any omissions. I distilled what is listed below from a prototype system coded up to evaluate Informix 4GL. In my prototype system, I have numbered all of my fields and can move directly to any field on any screen (I use a CTRL-F interrupt to pull up a window and prompt for a field number). This is actually a pretty slick feature and really helps move around...not only from screen to screen, but to "far away" fields without having to tab ad nauseum just to get to a field "way down there". I ommitted this code in the interest of clarity on the current issue. The prototype was tested and this multi-screen handler does work subject to the limitations mentioned above. I'll be happy to blast the code in its entirety to anyone who wants. Tom Rankin rankin@scubed.arpa ucb!ucsd!scubed!rankin (619) 453-0060 In a nutshell, here is the essence of the multi-screen code: ########################################################################### FUNCTION form_maint() OPEN FORM form0 FROM "form0" OPEN FORM form1 FROM "form1" OPEN FORM form2 FROM "form2" {Insert a menu which calls add, update, delete, etc.} CLOSE FORM form0 CLOSE FORM form1 CLOSE FORM form2 END FUNCTION {form_maint} {My add and update functions call the multi-screen handler which fills in "working storage" fields corresponding directly to the fields in the actual database table. Upon return from the multi-screen handler, the add and update functions perform the appropriate database commands to insert or update. Also, the Informix predefined "int_flag" field is checked in these functions to determine if a CTRL-C interrupt was encountered to abort commiting any changes to the database.} FUNCTION multi_screen() {F1 is used to go to previous screen} {F2 is used to go to next screen} DEFINE scrn_num SMALLINT DISPLAY "F1=Prev Screen; F2=Next Screen; ", "ESC=Commit Data; CTRL-C=Abort" AT 1,1 LET scrn_num = 0 LET int_flag = FALSE WHILE TRUE IF scrn_num = 0 THEN DISPLAY FORM form0 DISPLAY BY NAME work_field_1 THRU work_field_20 INPUT BY NAME work_field_1 THRU work_field_20 WITHOUT DEFAULTS ON KEY (F1) LET scrn_num = scrn_num - 1 CALL proc_screen_num(scrn_num) RETURNING scrn_num CONTINUE WHILE ON KEY (F2) LET scrn_num = scrn_num + 1 CALL proc_screen_num(scrn_num) RETURNING scrn_num CONTINUE WHILE END INPUT ELSE IF scrn_num = 1 THEN DISPLAY FORM form1 DISPLAY BY NAME work_field_21 THRU work_field_40 INPUT BY NAME work_field_21 THRU work_field_40 WITHOUT DEFAULTS ON KEY (F1) LET scrn_num = scrn_num - 1 CALL proc_screen_num(scrn_num) RETURNING scrn_num CONTINUE WHILE ON KEY (F2) LET scrn_num = scrn_num + 1 CALL proc_screen_num(scrn_num) RETURNING scrn_num CONTINUE WHILE END INPUT ELSE DISPLAY FORM form2 DISPLAY BY NAME work_field_41 THRU work_field_60 INPUT BY NAME work_field_41 THRU work_field_60 WITHOUT DEFAULTS ON KEY (F1) LET scrn_num = scrn_num - 1 CALL proc_screen_num(scrn_num) RETURNING scrn_num CONTINUE WHILE ON KEY (F2) LET scrn_num = scrn_num + 1 CALL proc_screen_num(scrn_num) RETURNING scrn_num CONTINUE WHILE END INPUT END IF {scrn_num = 1} END IF {scrn_num = 0} EXIT WHILE END WHILE END FUNCTION {multi_screen} FUNCTION proc_scrn_num(scrn_num) {Note that this is hard-coded for 3 forms...it should be evident how to generalize to more or less forms} DEFINE scrn_num SMALLINT LET scrn_num = scrn_num MOD 3 IF scrn_num < 0 THEN {handles wrap to last screen from first screen} LET scrn_num = 2 END IF RETURN scrn_num END FUNCTION {proc_scrn_num} ###########################################################################
eboneste@bbn.com (Liz Bonesteel) (11/09/90)
Having "resolved" my last problem with much appreciated help from net.folks (it was a known bug, but as we're running VMS [stop laughing!] it won't get fixed), I have another question. Currently I use two concatenated CONSTRUCT statements (one for each page of a two-page 4GL form) for my query. This works nicely; but if the user's query only applies to the first page, s/he still has to hit CTRL-Z twice to execute the query (first CTRL-Z moves to the second page). Is there any way around this; i.e., is it possible to hard-code a CTRL-Z into the program? All suggestions welcome. Liz