Re: ON KEY with EXIT INPUT: loosing field data

In article <3p9uvp$mne@newshost.centrum.is>, frantz@centrum.is says... > >akent@cix.compulink.co.uk ("Andy Kent") wrote: >> .... >> > However, I have run into the problem described in the INPUT manual page. >[compressed for brevity] >> .... >> Have a look at the get_fldbuf() function. > >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 INPUIT 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. >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? :-) 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. You don't have to go the cheezy way either with RECORD.*. You can explicitly declare each variable in the record in a GLOBALs file. And for those who say, "But what if the table changes?". Most of the systems I've worked on with explicit declarations in the code are easy to modify even if the tables change--which doesn't happen that often on production systems. If it does then go with RECORD.*. I don't program C programs with RECORD.*, and wouldn't do it in 4GL either. This is one of the two things that helps create sloppy code. The other is using one DEFINE statement and chaining every known variable to it. Yes, they compile, but they are shortcuts to good programming. Have the computer do the work and let it do some writing for you. >Whenever the program is changed and fields added or taken away, the >get_fldbuf() section has to be updated. In my book this is an 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. :-) >What is needed is a more general method that doesn't require maintenance. >One idea which may be tried is using a c function to put the accept key >value into the keyboard buffer. The 4gl code would then look something >like this: > > let accept_flag = true > input .... > > on key (f9) -- some key other than accept > let accept_flag = false > call put_accept() > .... > after input > if accept_flag then > .... > end if > end input > >Has anyone done this or have any other ideas? 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. -- \\\\|// [o|o] ==============================---o00--(_)--00o---============================ Tim Schaefer http://www.gate.net/~tschaefe The Computer Business Company, Inc. tschaefe@gate.net Coconut Creek, FL, USA INXUTIL 2.0 is now absolutely FREE He's dead Jim... --Dr. McCoy =============================================================================