Re: field navigation

Path: emory!europa.asd.contel.com!gatech!mcnc!rbdc!elsouth!john From: john@elsouth.wsnc.org (John White) Newsgroups: comp.databases.informix Message-ID: <1992Jan24.212810.6141@elsouth.wsnc.org> Date: 24 Jan 92 21:28:10 GMT References: <paulb.695992173@p4.cs.man.ac.uk> Organization: Electrical South Inc. paulb@p4.cs.man.ac.uk (Paul Bean) writes: >Is there a way to trap the direction in which the cursor is moving >through the fields on a form (ie forwards or backwards). I basically >want to ignore a next field x triggered by an after field y if i am >going backwards. >Thanks - Paul Bean Ummmm.... No. We have that problem too. We have a multiple column primary key and we want to do a referential integrity check as the users try to add info to one table that references the multi column primary key table. Example screen, make and part_no are the join columns: cust_no [ ] make [ ] part_no [ ] price [ ] After field is the wrong construct to use in this case for this type of checking because... o After field part_no will execute when the arrow key is hit to return to make, performing the ref_check yielding an error message that they already knew about. o You must also have an after field make in case they arrow up out of make. This stinks because of the duplication of code. The same problem illustrated above will happen here too. Another problem is when the user enters an ok make/part_no combo then realizes that, duh it isn't make=A, part_no=B it's make=C, part_no=D. They return to make and enter make=C, and move to part_no. AFTER FIELD make executes and calls ref_check(make=C, part_no=B). There is no C/B so they get an error and next field to make. So they have to null out make to get to part_no, null out part_no, return to make and start over. "GOD, DOES THIS SOFTWARE <insert expletive of choice>!!!" they tell you as they cover you with tar and feathers. "Ok, so after field isn't the way to go," you sez. "What's the solution?" axes you. Here be the best way we've found to solve this problem: Have a flag that gets set AFTER FIELD and says what field you've just left. In the BEFORE FIELD block of the cust_no and price, check the flag to see if you just came from either the make or part_no fields. Call your ref_check routine if so. Be sure to reset the flag. In the AFTER INPUT block, check the flag to see if they hit ESCAPE from inside the make or part_no fields and call ref_check if so. This sounds terrible, but it is the only way we've found to minimize the spaghetti, keep the user's happy, and keep the integrity. Having worked in UNIX at the curses level I'll defend Informix by saying that the inability to distinguish between arrows and returns is not Informix's fault. As payment for that service, I would like to request that Informix save us one of these work-around steps by setting the previous field flag for us. INPUT statements are bulky enough as is without having to have an after field block for every field. John White. john@elsouth.wsnc.org "Huh?" - Me, most anytime.