Path: utzoo!mnetor!tmsoft!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!uunet!ns-mx!tinyblue.cs.uiowa.edu From: brintle@tinyblue.cs.uiowa.edu (Lee Brintle,(Jones),3353183,3374010) Newsgroups: comp.databases Subject: Re: informix input array Message-ID: <4385@ns-mx.uiowa.edu> Date: 13 Feb 91 00:34:00 GMT References: Sender: news@ns-mx.uiowa.edu Distribution: comp Lines: 56 From article , by ahl@technix.oz.au (Tony Landells): > Well, I still seem to be fighting things, which suggests to me that > I'm doing something wrong, so I thought I'd ask for help again. Heh. From the Subject: line of your note alone, I guessed what your problems are. Even the volks at Informix hate INPUT ARRAY. > user hits delete key, but the code is in use and therefore the > record cannot be deleted--can you catch this in a BEFORE > DELETE clause and force informix to STOP the deletion > operation? > No. There are two solutions (probably more, but I know of two). The method given in Informix's Tech Notes is to use the EXIT INPUT command (which will not delete the row) and use a kludge to return to the spot in the array. The way I use in my programs is to rename the DELETE key (using the OPTIONS command) to something that the user cannot possibly type (I use F32). I then use an ON KEY command to handle all the processing that Informix normally uses. > user types over some information, changing it--if the old code > isn't in use, no problem (just like a delete followed by an > insert), but if the old code is in use, you need to propogate > the change... Do people just take copies of the data in a > BEFORE ROW (or FIELD) and then compare the values afterwards > to determine if it's been changed? > Yes. That's what I do, usually followed by a confirm window that makes sure that the user wants to make the change. Propogating accidental changes can be a real headache. The other option is to not allow changes; force a delete and a re-add. Which route is entirely implementation dependant. > Am I barking up the wrong tree? Should I force the users back to a > "one record per screen" approach with add/change/delete menu options? > This would seem like a BIG waste of screen space, as well as making > the process a lot slower for the user... > No. The command, though incomplete, can be tricked into doing what you want. > Also, in the stores example code, they use the function fgl_drawbox() > (or something like that, anyway). I note that this is in one of the > libraries, but not documented anywhere. Am I missing some > documentation, or are they using unsupported calls? > The undocumented call will continue to be supported, and I use it all the time. You may want to change the way the parameters work, though. It's a little counter-intuitive. Also note that you cannot easily draw straight lines with this function; there are little corners on the ends of the lines. > Thanks in advance, > Tony. Sure. Now, let's talk about RDS --> compiled portability problems. ;^) Lee Brintle, Advantage Information Management Lee Brintle | ``And so, I leave you with this final word: Advantage Information Mgmnt | twang.''