Re: DSPF numeric field editing

Within the program, right after the EXFMT I have:

if %int(futprc) = futprc; // user did not enter a decimal point (which is 99% of the time)
futprc = futprc / 10000;
endif;

The original field was (7,4) but to allow the user to enter a number with 4 assumed decimal places, I had to combine the (7,4) with a (7,0) and give them (11,4). This allows them to enter a 7-digit number (w/o a decimal) but still display it as (7,4).

It's ugly, I know. But when the boss, user, and auditor are all saying "Do it", you just do it.

TA



"Dennis Lovelady" <iseries@xxxxxxxxxxxx> wrote in message news:mailman.7063.1265647160.2580.midrange-l@xxxxxxxxxxxxxxx

Let's say they key in the number "2" and press Enter.
The program will assume four decimal places and divide by 10,000.

So far, still good.

If there are no errors or messages, the program will go back to the
first
screen and allow the user to select another record to be updated. But
if
there is an error or message (my message, not system message) the
program
loops around and does another EXFMT and the number shows up exactly as
they
keyed it in, ignoring any editing, even though the value is correct
(0.0002,
verified in Debug). I've tried an edit code and an edit word - neither
works.

The source that I see doesn't match the action that you describe. With a
numerically-defined field in the display file, the program will not be able
to determine whether the user entered a decimal point for integer cases. If
I enter 10.0000, that looks exactly the same coming into the program as 10
(no decimal point). That is unless of course, the rule works because
integer values are not acceptable?

Let's start with: are you sure that's what will happen, and are you sure
this is the right source?

Dennis Lovelady
http://www.linkedin.com/in/dennislovelady
--
"Success is going from one failure to another without losing enthusiasm."
-- Sir Winston Churchill