RE: Multiple screen forms in 4GL

I'm truly sorry to disappoint you all, but this time I'm not coming with an endless rant, but with an elegant, working solution instead. In this case the answer is drop inputs and use an input arrays instead, like thus, so that you are even allowed to flip pages with the next / previous page keys too! function input_page_1() # # open and display forms here, if required # input array prog_rec from screen_rec.* # # you can't use this, since you're using 4.00 - omitting it will do no harm # on key (insert, delete) continue input # # before/after field, on key clauses here # after row let d=intended_direction() # # your after input code here # exit input end input # # close form here, if required # return d end function # # more input functions here # function do_input() define p, d smallint let d=1 let p=1 while d!=0 case p when 1 let d=input_page_1() # # more input functions here # when n let d=input_page_n() end case let p=p+d case when d=0 exit while when p=0 let p=n when p>n let p=1 end case end whileend function function intended_direction() case when int_flag or fgl_lastkey=fgl_keyval("accept") return 0 when flg_lastkey=fgl_keyval("next") or fgl_lastkey=fgl_keyval("down") or fgl_lastkey=fgl_keyval("autonext") or fgl_lastkey=13 or fgl_lastkey=9 return 1 otherwise return -1 end case end function True input arrays can be safely used too, and you also can mix inputs and inputs arrays in one page. This should work nicely with your 4gl 4.00 too, since it completely avoids things like on key (nextpage) which were only supported from 4.10 onwards. This approach has the added bonus of code maintenance: no on key (next/prev page) clauses, no need to replicate code in after key clauses! As for the fgl_lastkey() function, have a look at the FAQ (see sig) - it shows how to create one on 4.00 4gl. Please note that you will have to pack into an array[1] of record (informix compilers complain about creative use of 4gl features, so you actually need an array to use an input array. You can use a plain screen record though) all the variables you need to input from one page. That means that you will not be able to insert into my_table values (my_rec.*) and will have to insert into my_table values (my_rec1[1].*, my_rec[2]1.*) A minor inconvenience. Note also that different releases of 4gl have different hang ups about input arrays (I bet JL knows them all). For instance 4.10 loops if an autonext is placed right before a noentry field, and does not honour the not null attribute unless you include a default value. 4.12 (or was it 4.13?) initializes a newly inserted row with the values of the previous one. HTH, Marco ____________________________________________________________________________ Marco Greco <marcog@ctonline.it> rem radioterapia 39 95 447828 fax 446558 Informix-FAQ http://www.iiug.org 4glWorks http://www.ctonline.it/~marcog --- On Sun, 15 Jun 1997 11:16:52 GMT Wookie <wookie@world.std.com> wrote: Hi, We're currently using Informix 4GL version 4.0 (Standard Engine) under SCO UNIX. The database is accessed by VT100 terminals. We have an application which necessarily has fairly big records and we are *desparate* to be able to have 4GL forms go over multiple screens (like they do in ISQL), so you can arrow down through the fields and at the bottom field the screen flips over to the rest of the fields. Then, when you've finished updating you can press ESCAPE for the whole record to be updated in one block. It also needs to work in the same way for queries and updates. So far, the only way I've found to do this is by splitting the fields up into two forms, and updating each one separately. But this is a MAJOR pain for the users of the application (who are not computer literate), as it means they need to do two database updates and cannot switch easily between the two forms. Things like queries and field updates are more complex too. Also, if the form expands to go over three screens, things get even more complicated. Does anyone know a way around this limitation? Is it fixed in later versions? I know that we could consider switching to a Windows front-end with ODBC which would get around the problem (using Access or something), but this is not possible at present. Thanks for any suggestions! Wookie -----------------End of Original Message-----------------