In Windows TFloatSpinEdit responds to changes in DecimalSeparator (if you update the control).
I noticed that in Linux GTK it does not.

(I use WinMe and Suse 10.0)

Observed behaviour GTK1
- DecimalSeparator at programstart: '.' (period)
- DecimalSeparator visible in control: ',' (comma)
- Changing DecimalSeparator and updating control: no effect

Observed behaviour GTK2
- DecimalSeparator at programstart: '.' (period)
- DecimalSeparator visible in control: '.' (period)
- Changing DecimalSeparator and updating control: no effect

Observed behaviour Windows
- DecimalSeparator at programstart: ',' (comma)
- DecimalSeparator visible in control: ',' (comma)
- Changing DecimalSeparator and updating control: Decimalseparator in control changes accordingly

While this is not a big issue, currently at GTK (in my situation) the Text of TFLoatSpinEdit possibly cannot be translate back to a Float because of the mismatch in decimalsSeparators used by the control and the one in SysUtils.

Does anyone know if GTK1/GTK2 even allows setting the character used for the FloatSpinEdit control (without having to change systemwide settings)?
If so, I consider it a bug and will post it in the bugtracker. If not, well, tought luck, and I'll live with it ;-)

Bart

Here are the docs for the gtk2 control:

http://library.gnome.org/devel/gtk/stable/GtkSpinButton.html

I cant find anything about the separator.

They probably use something from libc for the separator ... one would need to check the gtk source code and see what they are doing there.

You included clocale unit in your .dpr (UNIX targets only) ? DecimalSeparator at programstart: '.' (period) = DEFAULT , that means that clocale unit is missing.
DecimalSeparator visible in control: ',' (comma) = that means that gtk controls uses libc (right) locales, setted up by LANG variable.

zeljko

You included clocale unit in your .dpr (UNIX targets only) ? DecimalSeparator at programstart: '.' (period) = DEFAULT , that means that clocale unit is missing.

I was under the impression that the value of SysUtils.DecimalSeparator was determined/set at programstart using locale settings? (At least in Windows it seems to be)
Are they hardcoded in Linux version of SysUtils?

I'll try inclusing clocale unit and see what it does. Do I have to call some proc/function to make it set the value of DecimalSeparator?

DecimalSeparator visible in control: ',' (comma) = that means that gtk controls uses libc (right) locales, setted up by LANG variable.

And GTK1 differs form GTK2 with same locale setting?

What LANG variable should I look for?
(I'm not sure but I think I only saw one: it's value being nl_NL or something the like)

Bart

Under windows SysUtils have correct locales, but under unix (linux & mac) it's a mess, so that's the reason of clocale unit usage. With clocale included you'll get correct locales.

I'll try inclusing clocale unit and see what it does. Do I have to call some proc/function to make it set the value of DecimalSeparator?

No, but you can always say DecimalSeparator := ',';

if LANG=nl_NL then glibc (under linux) reads it's locale settings for nl_NL
eg.
DecimalSeparator := ',';
ThousandSeparator := ' ';
DateSeparator := '.';
ShortDateFormat := 'something'
if LANG=en_US then DateSeparator := '/' .... etc ...etc ...

SysUtils are not "multiplatform" in that case, so you have to use clocale unit.

zeljko

Shouldn't we then strive to make SysUtils use locale settings on all platforms? As it is now, it's rather inconsistent.

Maybe I should ask on the pfc mailinglist?

Bart

Bart wrote

Maybe I should ask on the pfc mailinglist?

Indeed.

As I know the core of the fpc rtl (and sysutils is there) does not want to depend on the libc but clocale unit is using it. Thus developers must decide themself whether to include it or not. But we can simple use it in some basic LCL unit as we do with cwstring so the problem will be solved.

I dont know what other lazarus developers think about this.

Best regards,
Paul Ishenin.

Since you use Libc anyway, I think this is the best way for the time being.

Unless of course Graeme Geldenhuys works through his meanwhile astronomic TODO list and implements the Locale checking himself in 100% Object Pascal :-)

Michael.

(On the subject of dependency on libc for locale formatsettings)

Unless of course Graeme Geldenhuys works through his meanwhile astronomic TODO list and implements the Locale checking himself in 100% Object Pascal :-)

Poor Graeme.
Done some digging into this aspect.
I'm not even sure this is at all possible without depending (directly or indirectly) on libc.

In theory one could determine which LC_xxx file we should use, and then parse the file.
However, the LC_xxx file structure is not the same in all libc versions (I know that at least libc 2.2 changed it), so that may be a problem (we would have to check libc versiion without linking libc? and respond to all changes in LX_xxx with new libc versions).

One could also execute locale with the right options (locale -ck LC_foo), pipe the output and process it to retrieve the values of decimalseparator etc, but that seems like cheating to me (we don't want to link libc but we execute locale which uses libc).

Back to the original subject.
Including clocale in the test program now makes sure SysUtil.DecimlaSeparator and SysUtil.ThousandSeparator have correct values: DS = , (comma), TS = #0 (not set).
However the TFloatSpinEdit control seems to use a hardcoded value for the DecimalSeparator it displays.
On GTK2 it is a period (.), on GTK1 it is a comma (,),

I'll file a bugreport on the subject.

Bart

Michael Van Canneyt wrote

Unless of course Graeme Geldenhuys works through his meanwhile astronomic TODO list and implements the Locale checking himself in 100% Object Pascal :-)

That todo item is slowly bubbling up to the top of my todo list. :-)

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Bart wrote

Done some digging into this aspect. I'm not even sure this is at all possible without depending (directly or indirectly) on libc.

Yes it is. At least under Ubuntu Linux 7.10 the package in question is called 'locales' and it does NOT depend on the libc package (and least under Ubuntu Linux and FreeBSD). The 'locales' packages is independent and is just a bunch of text files (mostly) containing locale information.

-----------------[ locales 2.6.1-1 ]--------------------- Description: common files for locale support

This package provides support for localized environments (locales). It installs character and transliteration maps, provides the POSIX locale definition and provides common scripts for language pack handling.

The actual locale definitions are not part of this package, these are shipped in the language packs and are installed and removed automatically.
------------------------------

Files in question are:
/usr/share/i18n/locales/aa_DJ
/usr/share/i18n/locales/aa_ER
/usr/share/i18n/locales/aa_ET
/usr/share/i18n/locales/af_ZA
/usr/share/i18n/locales/am_ET
/usr/share/i18n/locales/an_ES
[....snip....]

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/

Yes, i see. I have those files on Suse too.
Not sure what package is responsible.
An rpm -q locale (or locales) reveals nothing.

I was under the impression that actually the LC_xxx files in /usr/lib/locales/ determined the locale setting?

However the content of the files conflict with the info I get from locale

bart at simenon:~> locale
LANG=nl_NL.UTF-8
LC_CTYPE="nl_NL.UTF-8"
LC_NUMERIC="nl_NL.UTF-8"
[snip]
LC_ALL=

There is no /usr/share/118n/locales/nl_NL.utf8, only nl_NL and nl_NL at euro The latter copies (almost) all from nl_NL

From that file:

LC_NUMERIC
decimal_point "<U002C>"
thousands_sep ""
grouping 0;0
END LC_NUMERIC

from locale:
bart at simenon:~> locale -ck LC_NUMERIC
LC_NUMERIC
decimal_point=","
thousands_sep=""
grouping=-1;-1

See that "grouping" differs.
(I have not extensively checked other LC_xxx files)

Shouldn't we continue this discussion on fpc mailig list ()?
When I have time, I'll start playing with this.

Bart