Readkey

Smud

Smud

Member
try this;

READKEY PAUSE 86400.
DISPLAY LASTKEY.

What is the highest "PAUSE" seconds that does not break? Try running a second time with say 15000, and it works first time but not on a second run? Anybody else come across this?
 
No running 12.2 - I don't get a compile error - don't get to enter a key either but a "-1" displays. Thats the problem, the code does not wait for a key but continues with lastkey set to -1. Was allowing users to set a timeout in minutes and somebody decided to set it to 24hours.
 
Last edited:
Both Windows and Linux, first noticed on Windows as my test platform. If I set the seconds to something realistic its fine but users being users .... Nothing in the manual to say there is a limit.
 
Smud said:
No running 12.2 - I don't get a compile error - don't get to enter a key either but a "-1" displays. Thats the problem, the code does not wait for a key but continues with lastkey set to -1. Was allowing users to set a timeout in minutes and somebody decided to set it to 24hours.
Click to expand...

Immediately? Or after a set amount of time? Note: I'm using 12.2 x64.
 
"Immediately? Or after a set amount of time? Note: I'm using 12.2 x64." - Immediately! Yeah I'm running x64. Same on Linux version.
 
Smud said:
Immediately! Yeah I'm running x64. Same on Linux version.
Click to expand...
So also from a clean prowin or _progress session started from proenv?
I also tried 12.2 x64 on CentOS7 - no problem.

Are you running within some other environment / special startup parameters? What does:

Code: 
message replace( session:startup-parameters, ",", "~n" ) view-as alert-box.

Show?
 
I just tried:
Code: 
readkey pause 90000
12.2, AWS Linux.

It just sat there waiting for me to press a key. Should I let it run until tomorrow afternoon?
 
Not everyone was in today, still trying to find out of we update our clock from a central source (and so may have gone backwards in both platforms). It was hard enough tracking down the exact command where the App was failing, trick now is to replicate it and find out why. Keep you informed when I know more. Our clients have reported similar behavior in the past but I assumed it was something different.
 
Monday morning is when the clocks are sync'd (NTP) and this week was just under a 1/2 second move forward for the servers (which is the largest for a while). What the Windows machines were moved is not logged. So very probable the clock/time sync had issues and caused the "READKEY PAUSE n." to immediately return a -1 as the LASTKEY. Too much of a co-incidence, next time I know to just re-boot!
 
Another possibility is that maybe there was a mixup of timezone settings?

BTW, I'm told that another term for Strine is "Western Kiwi" ;)
 
Timezone issues is probably near the mark as the servers seemed to work fine up to a timeout of around 10 hours when I tried to find just where the problem "pause" was. Our time zone being GMT +10.

Despite what they think of us, I have a few friends from across the ditch :)
 
You must log in or register to reply here.
Back
Top