"Validate" confused by decimal separator

[m-planck]

In a lot of European countries a "," is used as decimal separator, not a ".". This is always a source of confusion in programs, especially if mixed up with the again switched thousand separator.

The validate button uses the local windows setting of the decimal separator and throws an error if in the simulation panel the decimal separator is "." and not ",", but by default loads the project file with a ".".

Only fix so far you have to change the decimal separator in the Windows control panel for ALL programs.

Could the validate function ignore the local regional settings?
Platform: Windows 10 2004 x86-64, German language pack

[fangq]

thanks for the feedback - mcxstudio wasn't widely used despite it has been included in mcx since 2009. We have been recommending mcxlab/mmclab to most new users because a majority of them have MATLAB (in an academic environment) and it is easier for pre/post processing. But I agree, we need to make sure mcxstudio GUI can handle situations like yours.

just to clarify - if you set your locale to German in Windows, when you type (dot) "." on the keyboard, it changes automatically to (comma) "," - is this correct? or users simply tends to type comma in the place of dot?

the DefaultFormatSettings.DecimalSeparator setting in lazarus is '.' by default, I am not sure if it changes under different locales

https://www.freepascal.org/docs-html/rtl/sysutils/defaultformatsettings.html

[m-planck]

A keyboard just send scancodes to the OS. The OS is responsible to display and interpret the right character, so depending on the language a scancode to character table is loaded. The "." and "," have the same location and scan code on an English or German keyboard (below the L key). The scancode for the numpad decimal separater key (below the numpad 3 key) is bound diffently, either to . or ,
So if I type a . it is a dot. If I use Excel the , is used (inputed) and shown, e.g. 3/2=1,5 and every function has a German name. However, in the binary file there is no change, so you can share worksheets between languages. Most of the programs do not localize the GUI, so you input . and often the , is automatically converted as . so it doesn't matter.

In mcxstudio everything is shown with . but the validate function insists on the local setting , So all inputs must be replaced with a , before the run button is activated.

[fangq]

thanks. can you copy/paste the text printed in the Output section (bottom) of mcxstudio when it encounters an error ? I just want to see what full command that mcxstudio assembled for mcx. A screenshot is also helpful.

[m-planck]

Output:
EXEPATH=C:\Program Files\MCXStudio\MCXSuite\mcx\bin\mcx.exe
Successfully loaded project C:\Users\[user]\Documents\MCXStudio\mcx_demo.mcxp. Please double click on session list to edit.
EXEPATH=C:\Program Files\MCXStudio\MCXSuite\mcxcl\bin\mcxcl.exe

[fangq]

I see. according to this lazarus thread, function StrToFloat uses locale-sensitive format settings for parsing numbers

https://forum.lazarus.freepascal.org/index.php?topic=48025.0

I believe that's what happened here because I used many StrToFloat calls to parse inputs

https://github.com/fangq/mcx/blob/master/mcxstudio/mcxgui.pas#L2830

Because StrToFloat is indeed locale-sensitive, I believe this should not impact new simulations manually defined by the user, but only becomes an issue when loading from a pre-configured simulation from a different locale.

Because i18n may involve many adjustments, I will keep this ticket open, and aim to get this fixed in the next release. I am also aware of a few OpenGL related bugs, such as Plot\Preview window no longer works once Plot fluence (nii) window is shown a couple of times. Could be a driver/OpenGL issue, or my code's issue. need to dig deeper on what happened, see

https://forum.lazarus.freepascal.org/index.php/topic,46771.msg376852.html#msg376852