INPUT ARRAY questions

Hi Folks, I'm using Informix-4GL 7.20 UD2 connecting to a SE database on SCO OS 5.0.5. I have two questions. When using an INPUT ARRAY, is there a way to keep a user from ADDING, or INSERTING (same thing maybe) new records? I want it to act more like a DISPLAY ARRAY, with the exception of being able to change fields within the rows that were selected and displayed with the INPUT ARRAY. Is there a way to map the Page-Up and Page-Down keys to scroll through the array? Thanks in advance.

Scott O'Connell wrote in message <95disf$2c3q$1@thoth.cts.com>... >Hi Folks, > >When using an INPUT ARRAY, is there a way to keep a user from ADDING, or >INSERTING (same thing maybe) new records? I want it to act more like a >DISPLAY ARRAY, with the exception of being able to change fields within the >rows that were selected and displayed with the INPUT ARRAY. > 7.30 has new, direct facilities for this. All earlier versions require dirty tricks. Simple way to prevent the user from pressing insert or delete line keys is to map them to something impossible: options insert key (control-s), delete key (control-s) But this doesn't stop them from "falling off the end of the array" and adding a new line there. If you wish to block that, post another message - the reply is more detailed.

"Andrew Hamm" <ahamm@sanderson.net.au> wrote in message news:3a7a51aa$1@news.iprimus.com.au... > Scott O'Connell wrote in message <95disf$2c3q$1@thoth.cts.com>... > >Hi Folks, > > > >When using an INPUT ARRAY, is there a way to keep a user from ADDING, or > >INSERTING (same thing maybe) new records? I want it to act more like a > >DISPLAY ARRAY, with the exception of being able to change fields within the > >rows that were selected and displayed with the INPUT ARRAY. > > > > 7.30 has new, direct facilities for this. All earlier versions require dirty > tricks. > > Simple way to prevent the user from pressing insert or delete line keys is > to map them to something impossible: > > options insert key (control-s), delete key (control-s) > > But this doesn't stop them from "falling off the end of the array" and > adding a new line there. If you wish to block that, post another message - > the reply is more detailed. Yes, the problem I'm having is that I want to keep them from arrowing down and creating new records. I wish there was a simple way to: BEFORE INSERT IF current_array = max_array THEN STOP INSERT MESSAGE "There are no more rows in the direction you are going." CONTINUE INPUT # keep user on last populated array line END IF ...etc. I'm not above dirty tricks with some guidance on how to use them. The last time I was using Informix was back on version 4.??, and I asked Informix for a "NEXT ROW." Never got it, came up with NEXT FIELD dummy with NO INPUT...it's a shame, but I'm still using that one. Did NEXT ROW ever creep into a release? What is the current method for getting 7.30? It tooks us three resellers and 2 months to PURCHASE 7.20 a year or so ago...nobody wanted to follow through and take our $13,000. Thanks again.

Scott O'Connell wrote in message <95dmbu$2g7j$1@thoth.cts.com>... > >What is the current method for getting 7.30? It tooks us three resellers >and 2 months to PURCHASE 7.20 a year or so ago...nobody wanted to follow >through and take our $13,000. > What country are you in??? That's appalling. I'll do the purchases for you and FedEx them to you for only a 15% markup if you like. Cash only of course, especially now that we've been blessed with an obscenely complicated GST tax system this last year. Before that paragraph, he wrote: >> >> But this doesn't stop them from "falling off the end of the array" and >> adding a new line there. If you wish to block that, post another message - >> the reply is more detailed. > >Yes, the problem I'm having is that I want to keep them from arrowing down >and creating new records. > Well, I've warned you... if you can't get a version of 7.30 in time, then here are the tricks: 1) forcing 4GL to the next row (bonus technique that's in the same area) Consider the "from" clause of input array my_proggie_array from screenie_array.* You may be using a screen record array or individual fields... IF you execute NEXT FIELD X and field X is a noentry field, then 4GL goes "looking" for an entry field after it in the record. Normally you could say that NEXT FIELD X is a waste of time and/or sloppy programming... BUT - if X is the last field of the screen record, then 4GL "finds" the next entry field on the next line. Thus you have a trick to force 4GL onto the next line. NOTE: I'm not talking about it's physical position as painted in the screen image, but it's logical position in the screen record. You can't use this trick to go backwards, but you can wrap the entire INPUT ARRAY statement in a loop and restart the input array, and put extra logic into the BFORE ROW block and - oh, it's too horrible to go any further. Also, if you have to move down dozens of lines, you'll see all the skipped-over lines spinning past in a flurry of activity. I've tried temporarily covering the input array with a blank window but it doesn't work. 2) Stopping 4GL from leaving a line: Once 4gl has decided it's time to leave a line, you ain't gonna stop it. The after row, after insert, before insert, etc blocks are useless for stopping the inevitable. The only place you can stop it happening is in the AFTER FIELD. That's a hassle because you are forced to write handlers for every field whether you like it or not. Talk about code bloat... first you need *(read disclaimer below)* define thekey integer somewhere in the declarations. It could be anywhere. Next, it's mandatory to have an AFTER FIELD block for *every* entry field so that you can put this little slab of code after every field that may be entered by the hot-fingered user: # format this any way you like;-) let thekey = fgl_lastkey() if arr_curr() = arr_count() and (thekey = fgl_keyval("down") or thekey = fgl_keyval("right") and infield(lastentryfield) or thekey = fgl_keyval("return") and infield(lastentryfield)) or (arr_curr() + NUMBER_OF_LINES_ON_THE_SCREEN >= arr_count() and thekey = fgl_keyval("nextpage")) then error " no more rows in the direction you are going. " next field thisfieldname # hmmm - I think the CONTINUE INPUT statement will do the trick end if BTW - test and substitute the bit about NUMBER_OF_LINES_ON_THE_SCREEN - you may need to add or subtract one - I can't remember. Can't test right now, but you can. Since this is really ugly and bulky, the closest you can get to something neat and tidy is: function can_i_leave(fldname) define fldname char(18), thekey integer let thekey = fgl_lastkey() if arr_curr() = arr_count() and (thekey = fgl_keyval("down") or thekey = fgl_keyval("right") and fldname = "lastentryfield" or thekey = fgl_keyval("return") and fldname = "lastentryfield") or (arr_curr() + NUMBER_OF_LINES_ON_THE_SCREEN >= arr_count() and thekey = fgl_keyval("nextpage")) then error " no more rows in the direction you are going. " return false end if return true end function ... before field x if not can_i_leave("x") then continue input end if ... other stuff Not pretty. Go for 7.3X 4gl where this nonsense can be left to rot in the pages of history. What 4GL needs is a good function pointer datatype. Or generic after field blocks ie after field "anything I don't care which". Just an idle thought. *DISCLAIMER* I haven't compiled any of this stuff, just looked at working code in another window and cut'n'pasted'n'modified the names to protect the innocent. If I've introduced any syntax errors then I know you can fix it %^)