I-4GL 4.10 Input Array Annoyance

>One of the most annoying features of the 4GL input array statement >occurs when the database has columns defined as not null and the user >hits ESCAPE on an empty line. Rather than realizing that the line is >empty, the program demands that the user enter something into the field. >There are several workarounds that I am aware of, all of which require >defining another key which will exit input. >This is horribly tedious. This also occurs in a situation where the key >elements of the row are scanned, and then lookups occur to display the >rest of the info for the scanned item before moving the next row for the >next scan. If the user wishes to move up and rescan the previous item >or change something, 4GL blithely informs them that such and such a >field requires input. This is an even worse case of >we-know-better-than-you from Informix. >Anyone know of an input array option which will eliminate this? Could >this be a function of using version 4 4GL with a level 5 database engine >(Online)? >I can't even find this feature in the manual. Please keep me from >letter-bombing Informix :-)? >Thanks. >Mike Lemon Try defining the fields in the form as formonly, without any constraints on them. Do all the necessary validation (not null, ranges etc) programatically. Do any complete row checking (for blank rows) in the after row and after input statements. You will also need to put the INPUT ARRAY inside a WHILE loop if you want to prevent them leaving a row if the after row checks throw up a problem. You will also need a NO ENTRY field, defined as the last one in the row, that you can use to force input array to skip to next row. Skeleton code below: LET exit_input = FALSE LET curr_row = 1 WHILE NOT exit_input INPUT ARRAY BEFORE ROW IF( curr_row > arr_curr() ) THEN NEXT FIELD no_entry_field END IF LET curr_row = arr_curr() AFTER INPUT IF( validation fails ) THEN EXIT INPUT END IF AFTER INPUT ....validation... LET exit_input = TRUE END INPUT END WHILE You will find that when the system is slow/arrays massive, the user will see the array scroll, but that shouldn't be a big problem... Mark Denham BBC London, UK Mark.Denham@bbc.co.uk