ahl@technix.oz.au (Tony Landells) (02/12/91)
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. My problem is that I have a number of tables that only really contain a short code (for data entry) and a longer description (for reports, queries, etc.). Given that each record EASILY fits on one line of the screen, I've been trying to use an INPUT ARRAY statement to manage the data. The other important thing about these tables is that a lot of other tables will be dependant on them. Now, I think I've got around the problem of people hitting the insert key, moving away, then coming back and entering data "unnoticed" by specifying in the form file that the fields are REQUIRED. However, how do other people handle the following: 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? 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? 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... 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? Thanks in advance, Tony.
lugnut@sequent.UUCP (Don Bolton) (02/13/91)
In article <AHL.91Feb12191828@saussure.technix.oz.au> ahl@technix.oz.au (Tony Landells) writes: >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. > >My problem is that I have a number of tables that only really contain >a short code (for data entry) and a longer description (for reports, >queries, etc.). Given that each record EASILY fits on one line of the >screen, I've been trying to use an INPUT ARRAY statement to manage the >data. The other important thing about these tables is that a lot of >other tables will be dependant on them. > >Now, I think I've got around the problem of people hitting the insert >key, moving away, then coming back and entering data "unnoticed" by >specifying in the form file that the fields are REQUIRED. However, >how do other people handle the following: > > 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? > Yep, call a function, tie it to BEFORE DELETE or on key DELETE test away and script according to taste :-) > 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? > You can make in effect a POST CHANGE mechanisim doing just as you suggest >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... > I get the vague impression that you are attempting to UPDATE table rows from an input array. BAD IDEA, also VERY BAD IDEA to allow the user to change the primary key value in the input array. BEFORE FIELD "P_key" if p_file.P_key IS NULL THEN NEXT FIELD P_key ELSE NEXT FIELD "next field" a quick (while I'm devouring lunch) memory flash. Informix reccomends a "delete and re-insert" method of update in an input array. While not my ideal choice, it does solve issues of switching between insert and update. >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? > UNDOCCUMENTED UNDOCCUMENTED UNDOCCUMENTED UNDOCCUMENTED When I was at the official 4gl class, the instructor clued us in on this. Funny you should spot it (was just about to play with it in my project tracking application). useage fgl_drawbox(1,2,3,4) the numbers mark the posistions you wish for the box boundraies. Youll need to experiment as to whether "2" is horizontal or vertical. (not a real good note taker) O>Thanks in advance, >Tony. Hope it helps
brintle@tinyblue.cs.uiowa.edu (Lee Brintle,(Jones),3353183,3374010) (02/13/91)
From article <AHL.91Feb12191828@saussure.technix.oz.au>, 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.''