View Issue Details

IDProjectCategoryView StatusLast Update
0003795FreeCADFeaturepublic2021-11-23 21:38
Reportermarkus51 Assigned ToopenBrain  
PrioritylowSeverityminorReproducibilityalways
Status feedbackResolutionreopened 
OSWindows 
Product Version0.17 
Target Version0.20 
Summary0003795: Input of floating point values with point ('.') instead of comma (',')
DescriptionI use FreeCad 0.17 with Win7, in Germany.
The country settings uses a comma (',') for floating point values.

Many peoples usees a point to input floating point valuses,
but FreeCad needs sometimes a comma, or sometimes are comma and points allowed.

Combo-View/Model: only comma
Combo-View/Tracks/Constaints: only comma
Spreadsheet: comma and points

I would be nice when always both floating formats will be accepted.


 

Steps To Reproduce1.) Create a new sketch and add some constraints with a length
2.) Double click in Combo-View/Tracks/Constraints on the new item
3.) Input "12.3" and press ENTER
4.) The new value is "123" instead of "12.3"

11.) Create a new sketch and add some constraints with a length
12.) Double click in Combo-View/Model on a Constraint
13.) Input "12.3" and press ENTER
14.) The new value is "123" instead of "12.3"

Tagsunits
FreeCAD Information

Relationships

related to 0003875 closed Spreadsheet workbench does not respect locale for decimal separator 
related to 0003963 resolvedopenBrain Only alpha comma key can be used as decimal separator 

Activities

Kunda1

2019-01-25 23:16

administrator   ~0012517

@markus51 Have you tested first in 0.18dev before posting (as we ask in the enormous yellow banner at the top of the page)?
We also ask very clearly at the top of the page not to post bugs (especially v0.17) unless they are verified in the forum.
Please download 0.18dev and verify 0003794 0003795 0003796

Kunda1

2019-01-25 23:16

administrator   ~0012518

@markus51 Have you tested first in 0.18dev before posting (as we ask in the enormous yellow banner at the top of the page)?
We also ask very clearly at the top of the page not to post bugs (especially v0.17) unless they are verified in the forum.
Please download 0.18dev and verify 0003794 0003795 0003796

markus51

2019-01-28 12:38

reporter   ~0012540

The same problem exists on version 0.18dev

uwestoehr

2019-01-28 13:04

manager   ~0012542

As a new user I stumbled over the same problem.
I get this with:

OS: Windows 7
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.18.15711 (Git)
Build type: Release
Branch: master
Hash: 5caae5f430237a73cd17e283d45b3ac9ab005feb
Python version: 2.7.14
Qt version: 4.8.7
Coin version: 4.0.0a
OCC version: 7.2.0
Locale: German/Germany (de_DE)

Kunda1

2019-01-29 18:17

administrator   ~0012553

CC @wmayer

wmayer

2019-02-21 16:48

administrator   ~0012714

When using a standard QDoubleSpinBox from the Qt library then it also changes the number to 123 when you enter 12.3.
This is because a dot in German locale is the group separator and not a decimal separator and the dot is only a visual aid for the user. When the user leaves the widget then it automatically removes the dot.
The QuantitySpinBox is a FreeCAD widget and follows the same logic as Qt's QDoubleSpinBox. So, there is no need to change anything with the current behaviour.

markus51

2019-02-21 19:01

reporter   ~0012718

I have fixed this ugly stuf in my private version (only 30 min work)
Now point and comma will be accepted.

That is user-friendliness !

uwestoehr

2019-02-22 00:20

manager   ~0012722

> Now point and comma will be accepted.

Very good. However I learned meanwhile that some German users use the dot to separate thousands. E.g. they input "18.000" and don't want to have it treated as "18,000" but as "18000". Therefore I understand @wmayer that FC should not add a workaround but let Qt do the job.

markus51

2019-02-23 12:30

reporter   ~0012729

German bakers usualy use the comma and sometimes a point to separate thousands.

German engineers use in the most cases the point. The geraman technical software which is writen in my company also uses the point for floating point values. Other technical software from other companies usualy to the same.

If we talk about financial software, you're right. In technical software, it looks a little different.

uwestoehr

2019-02-24 00:23

manager   ~0012735

> If we talk about financial software, you're right. In technical software, it looks a little different.

I recently realized that my engineer colleagues use µm as base unit instead of mm because we build microsystems. Always entering values like "0,060" annoyed them. So now they can write simply "60" and if there is a mm length, they then write 12.000.

Many engineering software offers to use the decimal separator of the UI language. That is why I did not yet noticed that - I use in most cases the English UI. Yesterday I made a test and setting the UI to German I have to use the comma. So things are changing in the software development and I think it makes sense to consistently follow the rules of the language.
The same is with FC. Use the English locale and you can use the dot as decimal separator.

Therefore I vote to mark this issue as already fixed since you can use FC with English UI andg get the dot as you like.

wmayer

2019-02-24 17:48

administrator   ~0012753

That is user-friendliness !

markus51
It's user-friendly for you personally but this does not mean that's user-friendly for everybody and it's at the cost of consistency.

Then in FreeCAD in dozens of places Qt's QDoubleSpinBox is used which strictly follows the locale settings of the OS. How do you deal with this, then?

uwestoehr

2019-02-24 18:15

manager   ~0012758

@wmayer I notice that there is an inconsistency because in tables FC automatically changes inputs like "2,3" to "2.3". Should I open a new tracker issue for that?

uwestoehr

2019-03-01 15:02

manager   ~0012815

> Should I open a new tracker issue for that?

I did it: 0003875

Since the spreadsheet issue is now covered I think this bug report could be closed.

Kunda1

2019-03-12 02:30

administrator   ~0012892

Closing ticket

uwestoehr

2020-03-24 13:23

manager   ~0014278

The discussion about this popped up again:
https://forum.freecadweb.org/viewtopic.php?f=3&t=35927
thus reopen the ticket for now.

uwestoehr

2021-11-02 14:57

manager   ~0016006

Was there any decision made for this?

@openBrain, do you maybe know something since you are assigned to a related bug?

openBrain

2021-11-02 17:35

developer   ~0016008

@uwestoehr : yes, the PR that was pending has been integrated and I required for testing here : https://forum.freecadweb.org/viewtopic.php?f=8&t=62546
AFAIK there is no regression declared ATM, but the fix may still be a bit incomplete. From the feedback, it works well for QSpinBox-like widgets, but not for example for Gui::InputField type.
I have to investigate to be sure this latter type can only hold "formulas" but no "expressions" before I extend the fix.

uwestoehr

2021-11-02 18:30

manager   ~0016009

Last edited: 2021-11-02 18:30

Thanks for your work!

> it works well for QSpinBox-like widgets

Not for me, I reported this now in the forum thread to be discussed further.

openBrain

2021-11-16 17:54

developer   ~0016033

@uwestoehr : new version has been integrated in daily that should work well in all situations. You can test again and report if needed. ;)

uwestoehr

2021-11-23 21:38

manager   ~0016051

How can I test this? I added the Boolean "SubstituteDecimalSeparator" under General in the parameters, then restarted FC but cannot see any difference. So e.g. an input of "3,0" results in 3 mm, but "3.0" results in 30 mm.

(By the way, reading my own statements from years ago, it is interesting how I changed my mind.)

yorik

2022-03-03 13:55

administrator   ~0016706

This ticket has been migrated to GitHub as issue 5871.

Issue History

Date Modified Username Field Change
2019-01-25 22:02 markus51 New Issue
2019-01-25 23:16 Kunda1 Status new => feedback
2019-01-25 23:16 Kunda1 Note Added: 0012517
2019-01-25 23:16 Kunda1 Note Added: 0012518
2019-01-28 12:38 markus51 Note Added: 0012540
2019-01-28 12:38 markus51 Status feedback => new
2019-01-28 13:04 uwestoehr Note Added: 0012542
2019-01-29 18:13 Kunda1 Tag Attached: units
2019-01-29 18:17 Kunda1 Note Added: 0012553
2019-02-21 16:48 wmayer Note Added: 0012714
2019-02-21 19:01 markus51 Note Added: 0012718
2019-02-22 00:20 uwestoehr Note Added: 0012722
2019-02-23 12:30 markus51 Note Added: 0012729
2019-02-24 00:23 uwestoehr Note Added: 0012735
2019-02-24 17:48 wmayer Note Added: 0012753
2019-02-24 18:15 uwestoehr Note Added: 0012758
2019-03-01 15:02 uwestoehr Note Added: 0012815
2019-03-02 02:01 Kunda1 Relationship added related to 0003875
2019-03-12 02:30 Kunda1 Status new => closed
2019-03-12 02:30 Kunda1 Resolution open => fixed
2019-03-12 02:30 Kunda1 Note Added: 0012892
2020-03-24 13:23 uwestoehr Assigned To => uwestoehr
2020-03-24 13:23 uwestoehr Status closed => feedback
2020-03-24 13:23 uwestoehr Resolution fixed => reopened
2020-03-24 13:23 uwestoehr Note Added: 0014278
2020-03-24 13:26 uwestoehr Relationship added has duplicate 0003963
2020-03-24 13:57 openBrain Relationship deleted has duplicate 0003963
2020-03-24 13:57 openBrain Relationship added related to 0003963
2021-02-06 06:49 abdullah Target Version => 0.20
2021-11-02 14:57 uwestoehr Note Added: 0016006
2021-11-02 17:35 openBrain Note Added: 0016008
2021-11-02 18:30 uwestoehr Note Added: 0016009
2021-11-02 18:30 uwestoehr Note Edited: 0016009
2021-11-02 19:14 uwestoehr Assigned To uwestoehr => openBrain
2021-11-16 17:54 openBrain Note Added: 0016033
2021-11-23 21:38 uwestoehr Note Added: 0016051