4gl bug or what ? Losing data on "next field next"

The following code doesn't seem to work. This is a dummied up version of my real code using the dbdemo database. If I have typed data to the fname field and then press Control-N the data is lost and the "After fname" section does not get called. Can the data be forced in and the After Field called without using the Accept key. I have a single table with multiple fields which are edited by using 6 screens. I only want the Accept pressed after all 6 screens have been filled in and use control-e and control-b to jump between screens. At present the data is lost if the current field has not been exited by tab or arrow. FUNCTION change_data() LET int_flag = 0 INPUT p_customer.fname THRU p_customer.phone WITHOUT DEFAULTS FROM sc_cust.* AFTER FIELD fname MESSAGE "After fname" ON KEY (control-e) # Just break out MESSAGE "Exit Input" exit input ON KEY (control-n) # Skip to next field MESSAGE "next field next" next field next END INPUT IF int_flag THEN LET int_flag = FALSE ERROR "Customer update aborted." RETURN END IF . . etc thanks glenn -- ///\\ BHP Information Technology, Newcastle, NSW, Australia. Glenn McNally \\/// #include <std.disclaimer> EMail: glenn@itntl.bhp.com.au

Glenn McNally wrote: > > The following code doesn't seem to work. > > This is a dummied up version of my real code using the dbdemo database. > If I have typed data to the fname field and then press Control-N the data is > lost and the "After fname" section does not get called. > > Can the data be forced in and the After Field called without using the Accept > key. > > I have a single table with multiple fields which are edited by using 6 screens. > I only want the Accept pressed after all 6 screens have been filled in and > use control-e and control-b to jump between screens. > > At present the data is lost if the current field has not been exited by tab or arrow. If your six screens have a hierarchy then do not exit the INPUT statement as the user moves down (^N) to the next form just call the function containing the INPUT statement for that form and return when the hierarchy is finished. Whenever the user finally hits the ACCEPT key, or the CANCEL key for that matter, just set a flag to the appropriate value and fall back up the calling stack to the initial form function. Either way, if you modify the logic or not, you can use the INFIELD() function, in the ON KEY (control-n) section, to determine which field the user was in when the user hit the NEXT FIELD key and then use the get_fldbuf( <fieldname> ) function to retrieve any input to the field before the key was hit and save it. See below: > FUNCTION change_data() > > LET int_flag = 0 > > INPUT p_customer.fname THRU p_customer.phone > WITHOUT DEFAULTS FROM sc_cust.* > AFTER FIELD fname > MESSAGE "After fname" > ON KEY (control-e) # Just break out > MESSAGE "Exit Input" > exit input > ON KEY (control-n) # Skip to next field CASE WHEN INFIELD( fname ) LET p_customer.fname = get_fldbuf( fname ) ... WHEN INFIELD( phone ) LET p_customer.phone = get_fldbuf( phone ) END CASE > MESSAGE "next field next" > next field next > END INPUT > > IF int_flag THEN > LET int_flag = FALSE > ERROR "Customer update aborted." > RETURN > END IF Art S. Kagel