comma separator decimal problem, units system

[jmaustpc]

Hi all

In German (I think), some locals anyway, use a comma as a decimal separator. Australia uses comma for thousands separator and decimal point for the decimal separator. I don't know about others. So I believe an attempt has been made in the units system to allow either comma or decimal point to be used as a decimal separator.

The problem is this interaction is causing a bug where the units system changes the size of objects due to the system and the units system interacting in an unexpected way......at least on my system.

Can other please test this and see if others or other locals are seeing this issue or not?

It works like this,
if you enter 9 m (9 metres) the system shows it as 9000mm (9 thousand millimetres) so far so good, the problem is that then my system displays the 9000 as 9 comma 000 (9,000) so now when I try to edit the value the units system takes the data and assumes the comma is a decimal separator, the units system then converts my 9m (9,000mm) into 9mm (9.000mm).


here is an example of how to see this issue.

create a new document, go to part design or sketcher WB, create a new sketch, insert a rectangle, set horizontal and vertical distance constraints on the horizontal and vertical edges and edit their value on creation to 9 m (9metres).

insert9m.jpg (8.28 KiB) Viewed 3621 times

Now look at the values in the sketch and taskview constraints list, they will say 9 thousand mm (for me "9,000 mm").

howitdisplays.jpg (48.73 KiB) Viewed 3621 times

Now if you try to adjust their values, as soon as you get units in edit mode it reads that 9 thousand mm as 9 decimal 000 hence only 9mm.

editingconvertsto9mm.jpg (8.58 KiB) Viewed 3621 times

and if you click OK without thinking, it of course resizes the sketch.

ifIclickOK.jpg (72.98 KiB) Viewed 3621 times

This is my version data....my units and most other settings are at the default values.

OS: Kubuntu 14.04 LTS
Word size: 64-bit
Version: 0.14.3685 (Git)
Branch: master
Hash: 63aed855ab484098510e02877bc3ce974c5acd09
Python version: 2.7.6
Qt version: 4.8.6
Coin version: 4.0.0a
SoQt version: 1.6.0a
OCC version: 6.7.0




Jim

settings_units.jpg (44.98 KiB) Viewed 3621 times

settings_general.jpg (57.98 KiB) Viewed 3621 times

[wmayer]

I can confirm exactly the same using German locale -- just the other way around.

When I e.g. enter "3m" for a pad, press OK and edit it again it shows "3.000 mm". Now when scrolling up it jumps to "8 mm" because the parser interprets "3.000" as "3" which is wrong. IMO it's a mistake that the unit parser handles both point and comma as a decimal separator.


OS: Windows 7
Word size: 64-bit
Version: 0.14.3684 (Git)
Branch: master
Hash: 2def3c03b881fc86990ba2c8c94e2f4a6ab949d6
Python version: 2.7.6
Qt version: 4.8.5
Coin version: 4.0.0a
SoQt version: 1.6.0a
OCC version: 6.6.0

[wmayer]

git commit b83f07f is a workaround for this issue. The idea is to disable group separators in Qt so that the conversion from double to string doesn't have one.

[nyholku]

Ancient thread, I know but I'm still experiencing this problem.


Below my installation detail. FFIW I'm in Finland but my MacOs region is set to "United Kingdom (Custom)".

Small ting but very annoying cause it makes the simple task of changing a number difficult.

Is there some workaround for this?


Attached is what I'm seeing:

OS: Mac OS X
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.17.12502 (Git)
Build type: Release
Branch: master
Hash: d2f4fcb6a2deec4aa4c0ba1501bf07df8aacd86e
Python version: 2.7.14
Qt version: 5.6.2
Coin version: 4.0.0a
OCC version: 7.1.0
Locale: English/UnitedKingdom (en_GB)