Re: INPUT ARRAY delete

Path: emory!wupost!zaphod.mps.ohio-state.edu!hobbes.physics.uiowa.edu!ns-mx!umaxc.weeg.uiowa.edu!lbrintle From: lbrintle@umaxc.weeg.uiowa.edu (Lee Brintle) Newsgroups: comp.databases.informix Keywords: INPUT ARRAY, delete Message-ID: <8640@ns-mx.uiowa.edu> Date: 15 Oct 91 21:54:47 GMT References: <1991Oct15.063248.27613@qualcomm.com> Sender: news@ns-mx.uiowa.edu Organization: U of Iowa, Iowa City, IA In article <1991Oct15.063248.27613@qualcomm.com> g_arne@bigbird.qualcomm.com (Arne Mortensen...guest) writes: >I often use INPUT ARRAY WITHOUT DEFAULTS and I typically end up doing >some kludgy thing to allow the user to bail out of a DELETE. For >example, if the user pressed DELETE on a row, I ask the user to confirm >the action and if the action is not confirmed, I EXIT INPUT and re-issue >the INPUT ARRAY (now updated up to the last user action). It would seem >that Informix should have the capability to allow the program to abort >the DELETE without forcing an abortion of the entire INPUT ARRAY. >Similarly, there are times that I want to restrict the user from performing >an INSERT. Informix's BEFORE DELETE and BEFORE INSERT clauses are silly; there's no way to say "don't do that" (see also: no way to prevent a user from pressing down arrow in an INPUT ARRAY). Best bet: re-map the DELETE and INSERT keys to something else (like F32), and write your own delete and insert routines triggered by ON KEY statements. Of course, this means that you always have to call "set_count" with the *maximum* number of items that can be added, there is no way to stop the user from going off the bottom of the "filled in" portion (well, no good way), and you cannot use the "required" clause in screen forms. But hey, that's the price you pay... hopefully, Informix will fix their INPUT ARRAY handling *one*of*these*days*. -- Lee Brintle | ``And so, I leave you with this final word: Leepfrog / Tanj | twang.''