Re: NEXT FIELD in AFTER ROW

In article <9095@emory.mathcs.emory.edu> dccrjc9@bpats (David Stockel) writes: >X-Informix-List-ID: <list.1264> > >Hopefully, someone who is running 4.1 can answer my question. >In my experience, if you have some validation in an AFTER ROW clause >and use a NEXT FIELD, the row movement is not canceled. You are put in >that field *but* on the wrong row. In my tests, when you hit the down >arrow, the error message is displayed, then the cursor moves down to >the next row before it moves over to the offending field. And that, as far as I can discern is *still* the case. I had posted to this group not too long ago about wanting to be able to trap keystrokes and choose to send them or ignore them. Aint there. >Just to be clear, these are not validations that I want to do with >AFTER FIELDs. I prefer to design screens that let the user add thing >in an arbitrary order. I only want to check things, like composite >keys, when they try to leave the row. > >The field engineer sound a little sceptical when I was explaining this >problem with the AFTER ROW. In any event, he assured me that problem >was probably fixed in version 4.1, since "they had practically rewritten >the entire thing" (I'm assuming the screen library). Not INPUT ARRAY they didn't. You musta been chatting with someone from marketing :-). They gave CONSTRUCT all the attributes of a real INPUT statement, BEFORE FIELD, AFTER, END CONSTRUCT which means you can "hide" a construct to the user behind a real input stmt. THey have legitimized EFLASTKEY (and not a moment too soon either) with FGL_LASTKEY and FGL_KEYVAL.. IF FGL_LASTKEY() = FGL_KEYVAL("DOWN") THEN IF EFLASTKEY = 2000 THEN still works too for those of us that were so enlightened before Informix decided to allow such functionality to the paying customers Both INPUT and INPUT ARRAY now have BEFORE INPUT and CONTINUE INPUT available. But once a "builtin" action code Ie: up/down occurrs there ain't no way to tell the software "hey don't do that". It would be *REAL* slick to be able to to reset the keyval and pass it upline. Ie: IF condition THEN set_fglkey("NO-OP"). ON KEY now accepts control sequences as well as the std (F1) etc Ie: ON KEY(^[[C) Maybe there may be a hack available this route. They have added a lot of nice things, "legitimized" some of the things already there that weren't doccumented. but INPUT ARRAY still is a *long* way from being "developer friendly". Don "its OK if you are paid by the hour though" Bolton