Kbase 20227: READKEY against COM port hangs Progress
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
06/10/2008 |
|
Status: Unverified
SYMPTOM(s):
READKEY against COM port hangs Progress when using the PAUSE <n> phrase
FACT(s) (Environment):
Progress 9.0x
Progress 9.1A
Progress 9.1B
Windows
CAUSE:
Bug# 19990120-003
CAUSE:
The details of the problem are noted in the following:
1) When using the PAUSE option of the READKEY statement, Progress had been ignoring the PAUSE and letting the system use a default timeout value (that is often a value that makes the system wait forever for input). This could happen even on Windows NT, but less likely than on Windows 9.x. If no device is attached or no data is coming in, it seems to be a hang.
Now Progress returns with either a byte (if there is one available) or -1 (if no byte arrives) during the timeout period. (Progress returns immediately, with or without a byte, when you use PAUSE 0.)
2) READKEY with a no PAUSE clause continues to let the system use the default timeout in case someone managed to create a working application that depends on this behavior.
The default actually uses whatever timeout was used the last time the port was opened, so it is possible someone could somehow set the timeout parameters and then successfully use READKEY with no PAUSE.
3) For READKEY to work, the port's other settings (baud rate in particular) must be set correctly. Even with the fix, the system can hang, or return garbage, if the settings are not correct.
If an application is not successfully reading from a com port, this factor needs to be checked (most developers should be aware of this. Here, this fact is stated explicitly for the sake of completeness and because of the following point.)
4) Unfortunately,Progress has another problem on Windows Version 9.x that works against the ability to set the com parameters successfully.
In test procedures, setting the baud rate through the Windows Control Panel did not always work because of an unreliable Windows API call that Progress makes. This call has the potential to set the com parameters to values other than what you established in the Control Panel.
Under Windows NT, Progress testers were able to use the DOS "mode" command to get around the problem (for example, "mode com2 baud=38400"), but under Windows Version 9.x, the mode command appears restricted to a maximum of 9600 baud and did not seem to help. Progress Development considers this problem an issue that needs further investigation and a bug report has been made.
5) The BINARY option on the INPUT FROM COM<n> statement does not work at this time. Progress Development considers this an issue and has submitted a bug report on it.
FIX:
Upgrade to Progress 9.1C