Re: ON KEY with EXIT INPUT: loosing field data

tschaefe@gate.net (Tim Schaefer) wrote: >>The get_fldbuf() is not practical in all cases. If you have a form with >>many fields, picked out of several records, the get_fldbuf() function >>is very tedious to use and ridiculous to maintain. >> >Depends on how you use it. I didn't discover the need for it until recently, >when I was using BEFORE/AFTER FIELD, and the values in the INPUT buffer were >not showing on the screen. So the get_fldbuf() was the answer. This seems >to happen on some systems ( DG/UX ) and not on others. I use get_fldbuf() extensively e.g. in "on key" clauses with infield() to handle particular fields. >>If the user is in any one of the fields and presses a key (other than >>accept) e.g. to jump to another form, he will lose any newly typed >>data in the field. >What system does this occur on? :-) What I meant is data is lost when get_fldbuf() is not used. Using get_fldbuf() by definition will retrieve newly typed data in a field. >> To use get_fldbuf() requires specifying every field >>in the form (in some cases it may be possible to use record.* notation). >> >This is where a template program generator can really help. Yes, field >management is tedious, especially for large screens. But using a program to >help write another program seems to work for me. I have to admit I'm quite ignorant of program generating techniques. >>Whenever the program is changed and fields added or taken away, the >>get_fldbuf() section has to be updated. In my book this is a bug trap, >>and it may be better to have all the fields never work right than some of >>them work and some not. >> >Is this true in all cases? Please elaborate so I can avoid this. :-) My point was that if an "on key" clause is to react in all the fields of a form and retrieve the field data before doing something else, all the fields of the form must be specified in a get_fldbuf() statement. If you add or delete fields from the form you (or whoever else, which is the main problem) has to remember to alter the get_fldbuf() statement. >Adding a C program is introducing a work-around that may have a narrow channel >of use, because of the wide variety of platforms. It's easier to create >programs with help from the computer, and have it write the BEFORE/AFTER FIELD >code. You use a code crank to prototype and get it right, then polish it up >for production. You're probably right on this. There is another consideration, however, which I can only describe with an example. Let's say you have a window with 2 input forms (e.g. a master/detail setup). The user fills in the first, moves to the second, and when all is ready he presses the accept key to fling the information to the database. The fields are validated, mostly in after field clauses, but also in the after input clause (e.g. things that pertain to the whole form). When the user moves to the other form via "on key" and get_fldbuf() grabs the latest field, the code in the after input clause is not touched. I'm not saying there aren't ways to get around all of this, but it's getting kind of messy. The C program method would cause the accept key to be triggered, thereby relieving the use of get_fldbuf(), and the after input clause would be executed. The 4gl code would be very simple.