DrDiettrich1 at aol.com
Wed Nov 26 16:54:57 CET 2014
> Of the OS/window manager actually. You are of course right in that there
> are a certain set of separators that can be used, but the exact
> separator to use is dependent on the system.
Sounds easy, but just yesterday I ran into a bunch of related problems.
Even if the following is somewhat OT, my observations may be helpful to
I just encounterd an really problematic case, with the Ez-Builder IDE.
That program aborts when the decimal separator is not a period '.',
asking the user to adjust his national/language settings in the system.
So what can/should a user do, in order to run this program on my German
Windows with a comma ',' as the decimal separator?
A developer might ask the author to add proper handling of the
system-wide national settings. But when that author spends time in
presenting instructions, how to change the inconvenient setting, instead
of correcting his code, I doubt that such a wish will be heard :-(
The dumb user might follow the instruction, causing problems in all
other programs :-(
When the system does not notify all other (running) programs of such an
global change, or when some other stupid program doesn't know how to
deal with changed settings, the user better shuts down and restarts his
system, before and after using that ill behaved program.
But exactly *what* should a clever program do, when it receives such a
change notification? What should happen with the formatted numbers,
shown in the forms of the program? Which code (app/OS?) puts the
separators into formatted number strings?
I don't know if it's worth to discuss such problems in detail, so let me
only present my preferred handling:
1) The actual settings are determined at program start, and remain
unchanged until program termination.
2) Formatted numbers, as enterd by the user (maybe by copy&paste from
other applications), can have various encodings. Before a conversion
into binary values I'd remove all unexpected characters, except for the
last (rightmost) '.' or ',', which then becomes the decimal separator as
expected by the decoding function (RTL provided).
3) For all other (non-GUI) purposes a unique string format is used,
according to the conversion functions used by the compiler. This means
no thousands separator, and a '.' decimal separator.
But back to the original problem: I managed to create another user,
whose number format settings match the expections of the Ez-Builder,
while using my German keyboard. For Linux users this may sound like an
easy job, but adding and configuring users in Win8 turned out as kind of
a nightmare :-(
Win8 requires an eMail address for every new user, but entering a fake
address only allows to create the account, without any chance to log in
subsequently. Probably the requested password has to be established by
mail, at least I found no way to disable or specify or reset the
password for the new account.
Fortunately I had retained an Guest account, could log in and adjust the
format settings as prescribed, and then could successfully start Ez-Builder.
After all I hope that these problems are due to the cheap (Premium?)
version of my Win8, that is *intentionally* crippled in several ways.
Proper handling of separators in formatted numbers is essential, or else
users may run into so big trouble, that they will drop your program as
More information about the fpc-devel