Lazarus
Programming => General => Topic started by: bmy92 on March 07, 2013, 10:48:25 am
-
Hi all,
I am a new user of Lazarus 1.06 (FPC 2.6.0), coming from Delphi.
My OS : Windows XP, french.
This instruction :
ShowMessage( Format('%10.0n', [1234567.0]) )displays: 1?234?567
Apparently, FPC produces an incorrect thousands separator (a space in my french locale)
Delphi 7 on the same computer correctly gives : 1 234 567
Did I forget something ?
-
You should set default.
DefaultFormatSettings.ThousandSeparator:=' ';
-
Strange.
Your sample code worked for me (it gave me a period which is correct for my locale) with laz 1.0.6+FPC 2.6.0 as well as Laz trunk +FPC trunk on Vista x64.
Perhaps it's a bug with xp + FPC!?
-
I see the same error with my new laptop with Windows 8, french.
Format does take into account the locale for the decimal separator (comma for France), but seems to bug with the thousands separator.
-
I add unit "clocale" to uses section of *.lpr file and I can reproduce on Linux. This should be reported.
-
The variable ThousandSeparator of sysutils is also incorrectly initialized.
I have created bug report 0024011 http://bugs.freepascal.org/view.php?id=24011
-
The bug report 0024011 was finally resolved as "No change required".
This is what I have understood (after hard thinking and many tests).
The non-breaking space provided with the Format function is a character of ordinal value 160 (hexadecimal A0).
This is non-breaking space in Ansi, but we need it in UTF8 encoding, that is hexadecimal C0 A0, or decimal: 192 160
The original problem seems solved with
ShowMessage(AnsiToUTF8(Format('%10.0n', [1234567.0])));
But the solution does not work if you have national characters and non-breaking spaces. This will display badly:
showMessage(AnsiToUTF8(Format('%10.0n mètres', [1234567.0])));A correct solution is to only convert the Ansi non-breaking space
showMessage(AnsiReplaceStr(Format('%10.0n mètres', [1234567.0]), #160, #192#160));
-
It does not work for me in console too. When I try simple program:
uses clocale, sysutils;
begin
writeln(FormatSettings.ThousandSeparator);
writeln(Format('%10.3n', [1234567.0]));
end.and in console:
fpc format.pas
./format
�
1�234�567,000Note that I have set no group separator for numbers and '.' for money in KDE4.
-
Hi,
But don't you think that the best and most natural solution is :
- the separator is converted during initialization to UTF8 or other charset if requested by the application
- the Format functions accept a multi-byte char as Thousand separator.
I think that other solutions have side effects and may lead to issues in some specific cases and environments.
And this way LazReport and other libraries will work with this separator and without any change.
Regards
-
(afaik this is already fixed in newer releases)
-
Good new, thanks !
However it is not fixed in 1.4.2
If someone knows in which version, I'm interested. Is it in FPC or Lazarus ?
-
It is not resolved it seems. FPC is in ansi, LCL requires utf8, and that bites.
Post http://forum.lazarus.freepascal.org/index.php/topic,20163.msg116623.html#msg116623 says it all.
I remember there being a bugreport but erroneously assumed it was fixed. It wasn't it was not fixable.
-
BTW, I have never got the console output to work with UTF-8 (opposed to the same write command to a text file). This applies even when using the fixes branch with fpc 3.01 and UTF-8 active in RTL (no FPC-LCL inconsistency), so it seems that console output is not a good test case?
-
Hi
I have created a bug (http://bugs.freepascal.org/view.php?id=28686) in FPC, to make possible to assign a multibyte character to separators.
Regards
-
It is not resolved it seems. FPC is in ansi, LCL requires utf8, and that bites.
Post http://forum.lazarus.freepascal.org/index.php/topic,20163.msg116623.html#msg116623 says it all.
I remember there being a bugreport but erroneously assumed it was fixed. It wasn't it was not fixable.
Even with both FPC and LCL set to UTF-8 with FPC 3.01 this is not solved according to my testing.
It could be solved by redefining the FormatSettings.ThousandSeparator to a string type. Then it could be assigned the proper UTF-8 code for Thin Space (U+2009) when needed. I do not know how much code would break because of this though.
The operative system's settings must also be able to deal with this - I wonder how it is defined there.
It seems that thin space as a grouping separator is gaining international support,
from https://en.wikipedia.org/wiki/Decimal_mark (https://en.wikipedia.org/wiki/Decimal_mark) :
" ...the International Bureau of Weights and Measures and International Union of Pure and Applied Chemistry advocate the use of a "thin space" in "groups of three".[15][16] Within the United States, the American Medical Association's widely followed AMA Manual of Style also calls for a thin space.[13]"
-
Hi otoien
Since you have a FPC 3.0, can you read and try the second solution proposed by Bart Broesma (use the "Set Utf-8 in RTL" option in Project Options) in my bug report ? I do not understand why, but may be he will explain...
By the way, I don't think a string is needed in ThousandSeparator, a double-byte char would do the job (with a "thin space" too).
Regards
-
Of course I have "Set Utf-8 in RTL" active through the compiler directive, that is the reason why I use the fixes branch with fpc 3.01 right now. FormatSettings.ThousandSeparator type is char that only takes one byte, so it is impossible to set it to a multi-byte value required for the UTF-8 version of thin space. I am not aware of any other type than string that can hold a multibyte-byte UTF-8 code point? [There is widechar, but I do not think it is intended for UTF-8, as it is fixed at two bytes; UTF8 may require more than 2 bytes].
-
Hi
http://wiki.lazarus.freepascal.org/FPC_Unicode_support#PWideChar.2FPUnicodeChar_and_WideChar.2FUnicodeChar (http://wiki.lazarus.freepascal.org/FPC_Unicode_support#PWideChar.2FPUnicodeChar_and_WideChar.2FUnicodeChar)
We need the {$mode delphiunicode} directive, to put UTF8 or other multibyte characters in a type Char, and it is not required AFAIK for strings.
Maybe the directive could solve the issue ? I can't try before a few days, let us know if you did.
Yes, your suggestion to declare Thousand separator use a string may work too, without requesting the directive, but I don't know if this will be changed in FPC.
Regards