Kbase P123804: Messaging characters using CHR function displays different characters in OpenEdge with -cpinternal I
| Autor |
Progress Software Corporation - Progress |
| Acesso |
Público |
| Publicação |
11/05/2007 |
|
Status: Unverified
FACT(s) (Environment):
OpenEdge 10.x
Progress 9.1x
Windows
SYMPTOM(s):
Messaging characters using CHR function displays different characters in OpenEdge with -cpinternal ISO8859-1 compared to Progress 9.1x
Different character is displayed in OpenEdge when Messaging character using CHR function with -cpinternal ISO8859-1 compared to Progress 9.1x
CAUSE:
The following statement will display an different character in OpenEdge if the startup is using -cpinternal ISO8859-1 than the one displayed by a Progress Session 9.1x
MESSAGE CHR(151) VIEW-AS ALERT-BOX.
This is expected behavior.
In OpenEdge 10, the GUI client is unicode-enabled.
OpenEdge 10 is displaying correctly.
CHR(151) in iso8859-1 is a control character, U+0097.
A convertion is made from -cpinternal to widechars so that calls to the widechar WIN32 APIs can be done.
The Unicode value of ISO8859-1 CHR(151) is taken, which is U+0097, and converted to widechars to pass to MessageBoxW().
If the font supports displaying this character, the character will display correctly, instead of the square.
In 9.1E, ASCII WIN32 APIs is used.
No convertion to the -cpinternal is made, but pass it raw to MessageBoxA(). Based on the user's Windows configuration, MessageBox thinks this is a 1252 character, not an ISO8859-1 character. CHR(151) in 1252 is U+2014 (EM DASH), which is displayed as hyphen.
To confirm this, use CTRL-C to copy the alert-box text to the clipboard, then paste this into Notepad. Save the text in Notepad, using UTF-8. If look at the text in a hex editor, it is possible to see the bytes E2 80 94, which is UTF-8 for U+2014.
FIX:
The OpenEdge Windows client session should be -cpinternal 1252 for Western European Code Pages.