Re: R4GL INPUT statement. Field input lost?

> jsturm@zenacomp.zenacomp.com (Jeff Sturm) writes: > david roper (daver@adam.com.au) wrote: > : I am using r4gl 6.02.UC1 but have always had this problem with earlier > : versions. > > : In an input statement, I use "ON KEY F3 ... EXIT INPUT". Remember you also loose this data if you do a next field inside the on key clause (at least in some versions). All this is a design flaw in Informix 4GL. This shouldn't ever have happened. Wysiwyg should clearly have been the rule here. The problems that gives could have been solved easier than the problems we now have. > : The problem is > : if the user has typed something into the current field and then presses > : the F3 key, the information they have just typed in not stored in the > : field. Is there a way to make this Information saved to the field without > : having to use a long set of "IF INFIELD()" statements? > > Would the get_fldbuf() function help with this? Maybe something like: > > on key f3 > let field_val = get_fldbuf(field_name) > ... > > I haven't tried this however. We do this as follows: call get_fldbuf(field1, field2...) returning p_field1, p_field2... where field1.. are the screen field names and p_field1... are the corresponding program variables. We put all fields of the input statement into this call so we don't have to test using if infield. There are however several problems: 1. This can't be put into a function?!&# get_fldbuf can only be called inside an input statement. You have to copy it into every on key clause plus wherever else you need it. 2. If a field is blank (no user input) the program variable will contain a space instead of null as is normal in an input statement. You need to call another function that sets all fields to null if they contain a blank if you want nulls in your database. 3. If you call a function that replaces the data in the p_fieldx variables while you are inside the input statement and display the data in that function, they aren't put into the field buffers of the current input- statement. (Usually if the displays are inside the input statement the field buffers are filled up - but there are limits to what we want to do.) In this case we do an exit input and reenter the same input statement to get the field buffers initialized correctly. We have also put a big case statement into the before input statement so we can put the cursor back into the field we want. 4. You have maintain all this. The question comes up why you want to exit the input statement via F3. If all you want is to let the user use the F3 key instead of ESC you could set the F3 key as the accept key via the options statement in 4GL. That would solve all these problems. If you want to execute some function you may be able to call it inside the on key clause. When the function returns you do not loose the keyed in data (but it is still not available of course to the program without get_fldbuf with its problems). While we are at it: This is about as bad as the field_touched function. Don't use that without thinking very hard about it. (field_touched is true if the user hit the space bar, but the program variable may not be changed - it is still null if it was before this. field_touched is also true if the user changes a value, and then changes it back to what it was. Fun...) Nils.Myklebust@ccmail.telemax.no NM-data, Dalsbergstien 7, N-0170 Oslo, Norway My opinions are those of my company