ahl@technix.oz.au (Tony Landells) (01/31/91)
I'm doing some development with Informix RDS and there are a couple of things I'd like to do but can't work out how... 1. Avoid the ERROR statement scribbling over my windows in its unfriendly manner. If I could replace the current error printing routine, that would be good enough, and seems to be the only way to get it to be sociable... 2. Catch up and down arrow keys in an INPUT ARRAY statement. I guess if I can do the above, this becomes less important, but I want to stop the user just skipping lines interminably at the end of the current data (which they can then move back to and fill in without triggering the AFTER INSERT clause). Thanks for your help... Tony.
dranney@informix.com (David Ranney) (02/01/91)
In article <AHL.91Jan31095437@saussure.technix.oz.au> ahl@technix.oz.au (Tony Landells) writes: >I'm doing some development with Informix RDS and there are a couple of >things I'd like to do but can't work out how... > >1. Avoid the ERROR statement scribbling over my windows in its > unfriendly manner. If I could replace the current error > printing routine, that would be good enough, and seems to > be the only way to get it to be sociable... You could reset the ERROR LINE in the OPTIONS statement. You could also use WHENEVER ERROR CALL to call an error handling function. >Thanks for your help... > >Tony. +------------------------------------------------------------------------------+ | David Ranney {uunet | pyramid}!infmx!dranney | | Informix doesn't pay me enough to write their opinions for them. | +------------------------------------------------------------------------------+
paul@unhtel.unh.edu (Paul S. Sawyer) (02/05/91)
In article <52042@sequent.UUCP> lugnut@sequent.UUCP (Don Bolton) writes: > >DISPLAY "Error message text" AT 23,1 > >be sure to do a DISPLAY "" AT 23,1 at a later point when you want >the message removed... For some reason, DISPLAY "str" will overwrite >only the space occupied by "str", yet DISPLAY "" will clear the entire >line. > Try: DISPLAY "Error message text", "" AT 23,1 -- Paul S. Sawyer {uunet,attmail}!unhtel!paul paul@unhtel.unh.edu UNH CIS - - Telecommunications and Network Services VOX: +1 603 862 3262 Durham, New Hampshire 03824-3523 FAX: +1 603 862 2030
lugnut@sequent.UUCP (Don Bolton) (02/05/91)
In article <AHL.91Feb2235852@saussure.technix.oz.au> ahl@technix.oz.au (Tony Landells) writes: >In article <52042@sequent.UUCP> lugnut@sequent.UUCP (Don Bolton) writes: > In article <AHL.91Jan31095437@saussure.technix.oz.au> ahl@technix.oz.au (Tony Landells) writes: > >I'm doing some development with Informix RDS and there are a couple of > >things I'd like to do but can't work out how... > > > >1. Avoid the ERROR statement scribbling over my windows in its > > unfriendly manner. If I could replace the current error > > printing routine, that would be good enough, and seems to > > be the only way to get it to be sociable... > > > DISPLAY "Error message text" AT 23,1 > >This isn't what I want...I actually have my own functions that display >errors nicely. The thing that really annoys me are the messages that >come from Informix itself that appear to be output as ERROR statements >(such as not inputting a required field, wandering off the end of the >program array with the arrow keys, etc.). Thus, I am hoping that if I >find a way to avoid the ERROR statements amusements, I will get rid of >these things over which I apparently have no comtrol. > > Or do you mean them "fatal errors" when the status returns "bad news" :-) > THose too can be rescripted to display your own messaging or call for > own functions whatever. Up to the developers imagination (and tenacity) > >No, those you can actually do something about with the WHENEVER >statement. > > WHY? does your program attemt to insert the null lines? Thats real easy > to test for and omit them when you're doing the actual insert. > > FOR counter = 1 TO arr_count() > IF p_varfile[counter].key_val IS NOT NULL THEN > INSERT INTO tablename (col, list) > VALUES (blah, blah) > ELSE > MESSAGE "" > END IF > END FOR > >This seems a bit sad, as the warning and the erroneous action are only >loosely associated. > Part of my correspondance course RDBMS training no doubt :-) > BEFORE ROW, AFTER ROW, BEFORE FIELD, AFTER FIELD > all of those allow you some leeway to handle input controll. > >This finished up being the only thing that appeared to work properly, >albeit with some sad repetition... > > OR Put a WHEN INFIELD on your first array field that won't let them > leave it blank > >I suspect this must be a 4.0 feature, and I forgot to mention that >this is for .03... The WHEN INFIELD seems totally unfamiliar to me. > No this has been around, an application I have that was written in 2.0 uses this, its part of CASE actually. Its isn't well doccumented though. I use it to force a user to remain in a manditory field until a value is input, rather than wait for the Informix built-ins to work. AFTER FIELD field list (of all possibly enterable fields in the array if you wish to create a case for each) CASE WHEN INFIELD(field_name) IF prog_file.col_name IS NULL THEN ERROR "Field cannot be left blank" NEXT FIELD field_name END IF WHEN INFIELD(X) IF etc END IF END CASE > Lotta options, Pain inna-rear when you are first trying the things out > though. Come to loathe the term SYNTAX ERROR have you? :-) > >No, but I thought that AFTER INSERT would be really whizzy, but it >doesn't appear to do anything terribly useful... If anyone thinks >this is being particularly unkind to INformix, then I will post an >extremely long explanation of what I was trying to do and what I >tried, and why it was unsatisfactory, ... I suspect the AFTER INSERT would be usefull for inserting dependant rows into child table IF a successful insert was done in the parent table. It would seem to be the only way to ensure some form of integrity in some cases, especially if part of the child rows id was part of a foreign key (aka serial) from the parent table. >Thanks for the input, >Tony.