V9 Handling Numerics on Input

[ljb1]

I am working on a v9.1d upgrade, currently at v8.3b. Our shop has Character Client based application on Windows.

I have encountered an issue with the code handling zeros on input in our v9 testing. The scenario is like this:
We have a screen with numeric input fields, default is zero. On input if the user wants to enter "000123" in the field, as soon as the first zero is hit on the keyboard, the cursor bounces to the next input field. In v8, the cursor would stay on the field until tab/enter was hit.

Any help on why this is happening or a work around would be greatly appreciated....

One more thing: I have modified some code to validate the input field as <> 0, so that it would not bounce to the next field until req'd to do so... But we have several instances where this it biting us and in some cases zero is a valid entry...

Thanks so much!
-ljb1

 

[vinod_home]

Hi,

Depends on your code. If you are leaving the field when its changed or something like that..

This simple code works for me on a character client.

<code>
def var vInt as int format "9999999" no-undo.
def var vSInt as int format "9999999" no-undo.

def frame x
vInt
vSint
.


do:

display vInt vSInt with frame x.
enable all with frame x.

wait-for close of current-window.
end.
</code>

 

[Huushawdadi]

Gday,

I'd tend to agree with vinod's first thought of whether you've got some for of trigger or event action defined when the field value is changed. Or perhaps defined for the "0" key.

That said,...could your terminal emulation in the v9 testing environment be incorrect? We've never experienced anything like what you're mentioning and we've been on v9 for a long time. We use vt100 emulation.

Oh, one other thought, I don't know if your problem is consistent or intermittent, but when we run vi and then run the progress session in the same window the emulation has been stuffed up and keys do not function as expected. I know that's probably not what you're encountering but hey..it's a thought.

Cheers

Breck

 

[Simon Sweetman]

ljb1: Are you using any EDITING blocks on your UPDATE statements or PUT CURSOR/PUT SCREEN statements? Perhaps try a simple program like this to test:

DEF VAR iValue AS DECIMAL DECIMALS 3 FORMAT "9,999.999" NO-UNDO.
DEF VAR cName AS CHAR FORMAT "x(60)" NO-UNDO.
UPDATE
	ivalue LABEL "Value"
	cName LABEL "Name"
	WITH SIDE-LABELS 1 DOWN.

Huushawdadi: Interesting about the running vi causing problems - have you tried one (or all) of these commands?

> tset
> tabs
> stty sane

 

[ljb1]

Thanks all for your help.
Yes, I am using editting blocks. I found that because I am defaulting to zero in the numerical fields that I had to remove the 'AUTO-RETURN' in the frame definition. I guess it was considering the field all ready filled in, therefore, it was jumping to the next field. I was hoping for a better solution, than having to touch all my code, but this seems to work. If it isn't the best solution, it is a workaround... and I don't have to think about it any more.

 

[Huushawdadi]

Thanks Simon,

The EDITING block was what I was trying to think of when I mentioned the triggers and events. Really irritating not having Progress installed on this PC to perform lookups.

And no, I haven't tried those commands for use with vi, are they to be used prior to (ie. .profile) or after using vi?

Breck

 

[Simon Sweetman]

After using vi - they should reset your terminal. Are you calling vi from a progress session with the UNIX SILENT command? I can understand how this would cause a fair amount of trouble with the progress display.

 

[Huushawdadi]

no, not calling from Progress at all. We were running a VT100 terminal emulation. Have found that running vi from unix prompt at any time before running progress executable removes cursor functions and some command keys when in the progress session, ie. traversing a CHUI menu.