Re: ON KEY (ACCEPT)

Ryan L Mcfall (mcfallry@cps.msu.edu) wrote: : Paul Fabozzi (merlyn@panix.com) wrote: : : Its 2 weeks before we are ready to go live with our program, and I ran into an : : interesting bug. When I use the ON KEY (ACCEPT) To test if the data in the : : INPUT is ok, It does not apply the current edited field, if im in one. : : IN OTHER WORDS: If a user updates a record, and goes to a field to update it, : : and after updating the field (while still in it) he hits ESC, the current : : field is not saved, it will be reverted. This is a nightmare for me, because : : I will have users that swear they updated something, and the database will say : : they are lying. : It would seem to me that it would be much easier to do the error checking : in "after input" instead of on key (accept), and simply "continue input" : if there's something wrong. (Of course, checking int_flag to see if they : pressed interrupt instead of accept). : Ryan : * Ryan McFall * : * Dept. of Computer Science * : * Michigan State University * : * mcfallry@cps.msu.edu * Ryan, It sounds like Paul is having trouble syncronizing the screen record (s_) wiht the parallel record (p_). Error checking in the after field logic might work, but I have found that after field logic is bypassed if you enter a field and then press escape. A more reliable test would be: To use some AFTER INPUT logic (p.110 in the 4gl supplement). Try testing the value of the field buffer. AFTER INPUT let scratch = get_fldbuf(field name) if scratch = s_form name.field name then EXIT INPUT else let s_form name.field name = scratch clipped end if EXIT INPUT There are some neat things in the 4gl supplement pertaining to this type of situation. There are also some neat tricks to use within construct statements. Good luck and careful coding. Scott@galileo.usa.net