Euro sign

Which font are you using?

Not all fonts have the Euro sign and some have it at a different position. I always use the character table accessory program (don't know, if that's the English name, but it's charmap.exe on Vista) to verify the Euro sign.

Good question.... and I suppose your next question is: which character set?

I have no answer to both questions. What happens when I use the default? What should I set instead? Where? How?

Maybe you can do something with CultureInfo?

DEFINE VARIABLE r AS CLASS System.Globalization.CultureInfo.

DEFINE VARIABLE i AS INTEGER NO-UNDO INIT 12345.

r = NEW System.Globalization.CultureInfo("nl-NL", NO).

MESSAGE i:ToString("c"). /* does not work */

VIEW-AS ALERT-BOX INFO BUTTONS OK.

MESSAGE r:NumberFormat:CurrencySymbol /* ? */

VIEW-AS ALERT-BOX INFO BUTTONS OK.

Hi Peter. Sorry for leading you in a possible wrong direction...

The default font is MS Sans Serif. The € sign is chr(128) in that font set. I tried things like:

CurrentCulture.NumberFormat.CurrencySymbol

This works in C# but in the ABL the result is a ? rather than a € sign.

I then switched the CPINTERNAL of my run configuration to utf-8 and it works then. Looks like some thing get's lost while crossing the bridge when using iso8859-1 ...

Appending CHR(128) to the string in the Text property does not work at all.

I'll log it as a bug.

By the way: Using a UltraMaskedEditor in Currency mode works fine. I guess this is because the Control get's the € sign already from the .NET end of the bridge.

W/R W808050132

Hi Mike,

Try -cpinternal 1252 instead. Euro is not part of the iso8859-1 codepage, hence the failure to convert. With my very simple case, it worked with -cpinternal 1252 but failed with -cpinternal iso8859-1.

Garry.

Works here as well!

I'm no code page exptert at all! Is 1252 a good replacement for iso8859-1? What are the consequences of changing that. And if so, shouldn't it be a default for cpinternal on a German/Dutch 10.2A installation?

For everything you might ever want to know about code pages, see http://www.i18nguy.com and http://www.xencraft.com/ . If memory serves, 1252 is a Windows code page, which makes for a good match with Windows apps, but isn't much of a match with anything non-Windows. ISO8859-1, on the other hand, is an international standard. You might try ISO8859-15, since I think that is a replacement for -1, but with the Euro.

Getting the CurrencySymbol from the CultureInfo works with 1252 and iso8859-15. But appending CHR(128) to the display of a numeric value ...:Text = STRING(42.17, ">>9.99") + " " + CHR(128) does ONLY work with 1252.

For iso8859-15 the € sign is CHR(164).

Confusing!

OT:

PF-file german.pf actually does point to codepage 1252 which works on Linux as well.

But PF-file dutch.pf does not specify a codepage at all.

I think Progress should take a good look at the prolang package...

uname

Linux

grep 1252 $DLC/prolang/ger/german.pf

-cpinternal 1252

-cpstream 1252

cat euro.p

put unformatted chr(128) skip.

bpro -pf $DLC/prolang/ger/german.pf -p ./euro.p > euro.txt

cat euro.txt

Batch processing will be performed using:

OpenEdge Release 10.1B02 as of Thu Jul 26 21:47:03 EDT 2007

€

You are right. The german.pf does use 1252. But my startup.pf in %DLC% does use iso8859-1. That has been the default during the install process.

AFAIK (I'm no code page expert) the german.pf is not used. It's just a template. startup.pf get's used. So that's the default.

Yes, install will create a startup.pf for you in the $DLC directory with settings that you are prompted for.

You can download prolang from the Progress website with the settings like promsgs, startup.pf and empty database for each language.

If you want all Progress sessions to use these settings you can copy these specific language settings over the $DLC/startup.pf file.

BTW

You could maybe also use the ultraCurrencyEditor and set the FormatProvider property so all things like the decimal/group separator, number of decimal digits are automatically used.

DEFINE VARIABLE r AS Infragistics.Win.UltraWinEditors.UltraCurrencyEditor NO-UNDO.

r:FormatProvider = NEW System.Globalization.CultureInfo("nl-NL").

You could use the users OS settings and use it in your applications appearance. Use a webservice to get the latest exchange rate and rework the numbers... And... Getting carried away here...

Confusing!

Such is the nature of i18n!

Try -cpinternal 1252 instead.

Yes this works! Thanks.

I did not realize that the standard OpenEdge rules applied here as well. Cool!

-peter