Re: array ?

spitz@GANS2X.ana.med.uni-muenchen.de (Richard Spitz) writes: >: For each *row* in the array, there is a bit of trickiness, so if that's >: that you really wanted, repost and I'll provide the long-winded >: solution. >Why not just write > BEFORE ROW > LET arr = arr_curr() > LET scr = scr_line() > DISPLAY array[arr].* TO screenrecord[scr].* ATTRIBUTE(REVERSE) > AFTER ROW > DISPLAY array[arr].* TO screenrecord[scr].* ATTRIBUTE(NORMAL) >This works for me. You might want to add some logic so that no empty rows >are displayed reverse if you go beyond the last row. This is the trickiness I was alluding to. If you allow INSERTING the row, either by moving to a row beyond set_count() or with the INSERT key, you'll find that the wrong row is highlighted (because the BEFORE ROW control block is executed before the blank row is opened up). This is not so much a bug as an anomaly of the INPUT ARRAY (and I even said that *before* I was an Informix employee!). The "simpliest" solution to the problem is to have a NEXT FIELD statement in the BEFORE ROW control block to go to the first field in the row, then displaying the reverse in the BEFORE FIELD statement: BEFORE ROW LET arr = arr_curr() LET scr = scr_line() NEXT FIELD a BEFORE FIELD a DISPLAY array[arr].* TO screenrecord[scr].* ATTRIBUTE(REVERSE) AFTER ROW DISPLAY array[arr].* TO screenrecord[scr].* ATTRIBUTE(NORMAL) The only "problem" with this approach is that if the user goes up/down to a row by typing the up/down arrow key from any field other than the first, the cursor moves to the first field in that row rather than the same field from which the cursor left. In most cases, I've found this actually desirable (if the users can live with it), since it makes BEFORE/AFTER FIELD control quite a bit easier. Now, aren't you sorry you asked? >I have always been angry that this doesn't work with DISPLAY ARRAY. I am >sure that it would be easy to implement BEFORE ROW/AFTER ROW etc. in >DISPLAY ARRAY just as in INPUT ARRAY, and this has been near the top of >the wish list for 4GL for a long time. Why has it not been implemented? My 2 deutchmarks worth: DISPLAY ARRAY is a "quick and dirty" way to displaying an array's worth of data. All functionality you want for DISPLAY ARRAY are available by coding it as INPUT ARRAY and disallowing input via NOENTRY fields and the like. My point is: where do you stop when adding features to DISPLAY ARRAY that makes it look more and more like INPUT ARRAY? If you need more control over the display/actions of an array than DISPLAY ARRAY offers, code it as INPUT ARRAY. Added functionality for DISPLAY ARRAY has never be high on *my* 4GL feature request list; I'd rather R&D spend time on adding features we can't do in any way; like get_fldbuf() did for us. Now, aren't you *really* sorry you asked? ======================================================================= Dennis J. Pimple dennisp@informix.com Opinions expressed Senior Consultant -------------------- are mine, and do not Informix Software Inc Voice: 303-850-0210 necessarily reflect Denver Colorado USA Fax: 303-779-4025 those of my employer. (the last remark is bad American humor: I hope it translates as such) >Regards, Richard >-- >+----------------------------+-------------------------------------------+ >| Dr. Richard Spitz | INTERNET: spitz@ana.med.uni-muenchen.de | >| EDV-Gruppe Anaesthesie | Tel : +49-89-7095-3421 | >| Klinikum Grosshadern | FAX : +49-89-7095-8886 | >| 81366 Munich, Germany | | >+----------------------------+-------------------------------------------+