#197 Extended screenIO accepting numeric data
For as many years I have been using OC & GC I have been forced to used
extensive accepts when dealing with numeric and money fields.
For example wishing to accept 9(6).99 as money I would like the system
to cope with user keying 12.99 or 0.49
This field is redefined as 9(6).v99 and displayed before accepting first
the 9(6) then the 99.
Most painful and clunky for the user that may well be inputting a large
number of these values.
Without having to move the cursor (using arrow key to the right) before
getting to the decimal element.
This was the way using MF and this simple recognised the period key and
moved the cursor to the right of dec waiting for the decimal element/s.
How [ suggestion ] ?
Under the old MF compiler such as workbench I 'think' it was ADIS that
was involved but regardless the only trigger would be a numeric or
numeric edited field target that would need to trigger extra processing.
So the compiler would need to issue a call to a small C process that
would act based on the picture e.g.,:
Is there no (input) editing - if true take accepted chars and more to right (& redisplay) after any key that acts as enter including right arrow. Edited field process as two sub steps 1. pre-decimal and 2 post-decimal. A. Again for pre, act on a entered period by moving and redisplay value to the right but left of period then move cursor to right of period. B. Process decimal clearing any unused chars not entered before exiting for next field processing.
Easy - but might have left a few steps out.
... and no my C skills are far too rusty to try this but still heavy
into ACAS upgrades for rdbms and manuals
A work around is to ACCEPT a PIC X or group field. Then convert it to numeric. Modify the following to your needs. You may wish to left justify WS-DECIMAL just before the ACCEPT for easier entry.
It is recommended to re-display the number after the NUMVAL. In case the user entered letters "I" or "O" for numbers "one" and "zero", etc.... The re-displayed number may be left justified for better readability.
Will that method reposition when accepting the period as I cannot see that happening at least during field entry.
Think of the problem where a user may be entering a large amount of monetary values during a day.
Ranging from (say)
0.04to99999.99and everything in between.It really suggests that what ever method is used you can do this on a field with
PIC 9(6).99( assuming signage could be specified at any end e.g., leading or trailing) subject to design requirements.Now user enters
123.45.Currently if entered in a group field it has to be cleaned up then maybe (re)displayed as against;
Enters
123.[ one two three period ] then the data is redisplayed correctly positioned with the cursor at the left most decimal value waiting for more keyboard entry as it understood the entry of period.This is the MF way along with many compilers just not GC.
It make doing similar but not the same difficult not to say almost impossible unless we only accept one character at a time and when getting a period redisplay correctly positioned for remaining input.
For a few fields of this ilk is a pain but not difficult but if many the amount of code to deal starts to get excessive when some C coded library to handle would be a lot easier.
I do deal with this in ACAS but it is not the right way for user doing a lot of it !
Sorry, have repeated my self a bit...
Vince
Last edit: Simon Sobisch 2017-07-26
Partially done in [r3729]. Remains to add tests, maybe runtime configuration options and code to make cursor jump to appropriate digit on entering a numeric field.
Last edit: Edward Hart 2020-07-20
I think this is the right place to add the attached documentation describing the desired behavior from the system (after an -
ACCEPT field- statement) when the user has to type a numeric field with decimals and sign.Last edit: Eugenio Di Lorenzo 2024-09-08