FreeCAD Forum

Posted: **Fri Mar 27, 2020 11:56 pm**

Good find!

Posted: **Sat Mar 28, 2020 3:21 am**

Evening Ladies and Gentlemen,
I was just looking over the data submitted and some additional details caught my eye.

dubstar-04 wrote: ↑
Thu Mar 26, 2020 10:37 pm
Evening All,
I have noticed the same issue when using the profile edges Op.
Watch the value of extra offset:
...

herbk wrote: ↑
Sun Mar 22, 2020 3:35 pm
Hi Russ,
OK...here with some pics:
i set the values for BoundBox extra offset and Sample Interval to 1mm and close the UI by clicking OK
I reopen the UI by doubteclick the Operation and get this values shown. Closing the UI by OK shows the path calculetet by this values.
reopen the UI shows again increased values...
My number of decimals is only at 2 and also the precision of path calculations is only at 0.01mm

Observations:
First, I just noticed that @Dubstar-04, your error is an increase of 100 each time, whereas that of @HerbK is only a factor of 10. This is indeed an interesting issue!

Second, is this a display only error, or are the paths(operations) being affected according to the new erroneous values?

Third, are all the expression-aware fields unaffected by this error as you have been checking different input boxes in PathWB? If so, perhaps we need to convert the erroneous boxes to expression-aware and be done with the whole lot.

Fourth, we might ought to discuss the possibility of adopting straight Qt classes, as @Freman pointed out earlier in this topic, for the input boxes. It might be worth discussing the idea and its consequences. I do imagine the `Gui::XXX` classes used provide some necessary elements to the user-input interface. Perhaps I better jump back to the parallel topic that ChrisB posted, and read through again to see if I can better understand what they are discussing as possible causes for the issue they are facing (whether related to our issue here in PathWB or not).

Fifth, perhaps we need to consider, or experiment with, changing some, or all (if successful), of the `Gui::InputField` class to the `Gui::QuantitySpinBox` class. Perhaps it is not prone to this `increase by a factor of 10/100` issue.

Action taken:
I changed the code in the gui modules in the current 3D Surface/Waterline split PR. I edited the PathSurfaceGui and WaterlineGui modules. I copied the code method used for DepthOffset in the setFields() function, and applied it to SampleInterval and both BoundBoxExtraOffset inputs in the same setFields() function. I made these changes in both the PathSurfaceGui and WaterlineGui modules. I am hoping that this will fix either the `factor by 10` or the `factor by 100` issue. Either way, at least implementation will be consistent.

Facts:

The widget class for each of the properties mentioned above, including OffsetExtra in the ProfileEdges module, is `Gui::InputField` within the .UI task panel files.
Currently (pre split PR merger), the DepthOffset in 3D Surface and OffsetExtra in ProfileEdges use the same code method in their respective Gui modules:
Code: Select all
```
self.form.extraOffset.setText(FreeCAD.Units.Quantity(obj.OffsetExtra.Value, FreeCAD.Units.Length).UserString)
```
. In the split PR, I applied this method to SampleInterval and BoundBoxExtraOffset.
Each of the properties mentioned above are of the type `App::PropertyDistance`.
We have at least three different locales represented.
We have Qt 5.12.5 (openSUSE Leap 15.1), 5.12.1 (Windows 10), 5.12.5 (macOS High Sierra), 5.14.1 (openSUSE Tumbleweed), 5.11.3 (Debian GNU/Linux 10 buster)
We have Coin 4.0.0 (openSUSE Leap 15.1), 4.0.0a (Windows 10), 4.0.0 (macOS High Sierra), Coin 4.0.0 (openSUSE Tumbleweed), 4.0.0a (Debian GNU/Linux 10 buster)
We have OCC 7.4.0 (openSUSE Leap 15.1), 7.3.0 (Windows 10), 7.4.0 (macOS High Sierra), 7.4.0 (openSUSE Tumbleweed), 7.3.0 (Debian GNU/Linux 10 buster)

Okay. This is my two pesos. Sorry, México, but my thoughts ain't worth two cents at this point.

Russell

Posted: **Sat Mar 28, 2020 7:41 am**

Each of the properties mentioned above are of the type `App::PropertyDistance`.

Good work Russ.

This does concord with my suggestion that it may have been my PR which was the trigger for the resurgence of this problem since it changed three of boundbox inputs from PropertyLength ( unsigned ) to PropertyDistance ( signed ). That is globally a positive event since this needs to fixed.

Above I referred to "locale". In unix world this refers to settings which determine user language, currency , number format etc. In listing the various platforms above you do not note the language used ( from which we can guess the number format ). IIRC Chrisb is MacOS/german settings. Most complainants seem to be from Germany. The odd exception being dubstar Locale: English/UnitedKingdom (en_GB) in mm.

I don't know whether this reflects the user base or is a factor in the bug. Maybe anglophone users are more used to buggy software and just accept it as a fact and get on with life , whereas Germans expect things to work and take the time to report the problem to ensure they do.

My libc is not compiled for DE support but I do have FR which also uses comma decimal separator. Setting locale to fr_FR.utf8 and setting FreeCAD language to french in the UI does NOT reproduce the bug shown by dubstar.

Posted: **Sat Mar 28, 2020 9:10 am**

I'm afraid we cannot rely on the FreeCAD infos concerning the language environment

export LANG=en_US.utf-8:
Everything ok, no multiplication

OS: Ubuntu 16.04.6 LTS (Unity/ubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.20209 (Git) AppImage
Build type: Release
Branch: master
Hash: 5fc4a26a00390e91cbf91848b766b68ad87e5917
Python version: 3.8.2
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United States (en_US)
--------------------------------

export LANG=de_DE.utf-8 or
export LANG=de_DE
Not ok, multiplication factor: 10
Please note that the locale shown in FreeCAD infos did not change.

(I see some error messages on startup, obviously there are workbenches showing issues with non ascii characters, even if I set the utf-8 variant)

OS: Ubuntu 16.04.6 LTS (Unity/ubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.20209 (Git) AppImage
Build type: Release
Branch: master
Hash: 5fc4a26a00390e91cbf91848b766b68ad87e5917
Python version: 3.8.2
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United States (en_US)
-----------------------------------

export LANG=en_GB
No multiplication factor, still the same FreeCAD info:
(I still see the error messages)

OS: Ubuntu 16.04.6 LTS (Unity/ubuntu)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.20209 (Git) AppImage
Build type: Release
Branch: master
Hash: 5fc4a26a00390e91cbf91848b766b68ad87e5917
Python version: 3.8.2
Qt version: 5.12.5
Coin version: 4.0.0
OCC version: 7.4.0
Locale: English/United States (en_US)

Posted: **Sat Mar 28, 2020 9:25 am**

And the same test with ProfileEdges ExtraOffset:

export LANG=en_US.utf-8
multiplication by 100

export LANG=de_DE.utf-8 or LANG=de_DE
No multiplication! (see me surprised, almost shocked)

export LANG=en_GB.utf-8
multiplication by 100

Posted: **Sat Mar 28, 2020 9:44 am**

Chris I don't have a lot to do with *bunty variants, are you using Gnome desktop, that may be interfering. [EDIT Unity is gnome based]

Code: Select all

export LANG="fr_FR.utf8"

locale
LANG=fr_FR.utf8
LC_CTYPE="fr_FR.utf8"
LC_NUMERIC="fr_FR.utf8"
LC_TIME="fr_FR.utf8"
LC_COLLATE="fr_FR.utf8"
LC_MONETARY="fr_FR.utf8"
LC_MESSAGES="fr_FR.utf8"
LC_PAPER="fr_FR.utf8"
LC_NAME="fr_FR.utf8"
LC_ADDRESS="fr_FR.utf8"
LC_TELEPHONE="fr_FR.utf8"
LC_MEASUREMENT="fr_FR.utf8"
LC_IDENTIFICATION="fr_FR.utf8"
LC_ALL=

./FreeCAD

OS: Fedora 31 (Thirty One) (LXDE/LXDE)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.19591 (Git)
Build type: Release
Branch: 3D
Hash: 27771fc6ee93170b6ecb978ff4da438a5b9cfe97
Python version: 3.7.6
Qt version: 5.13.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: French/France (fr_FR)

Code: Select all

export  LANG=en_GB.utf8

locale
LANG=en_GB.utf8
LC_CTYPE="en_GB.utf8"
LC_NUMERIC="en_GB.utf8"
LC_TIME="en_GB.utf8"
LC_COLLATE="en_GB.utf8"
LC_MONETARY="en_GB.utf8"
LC_MESSAGES="en_GB.utf8"
LC_PAPER="en_GB.utf8"
LC_NAME="en_GB.utf8"
LC_ADDRESS="en_GB.utf8"
LC_TELEPHONE="en_GB.utf8"
LC_MEASUREMENT="en_GB.utf8"
LC_IDENTIFICATION="en_GB.utf8"
LC_ALL=


./FreeCAD

OS: Fedora 31 (Thirty One) (LXDE/LXDE)
Word size of OS: 64-bit
Word size of FreeCAD: 64-bit
Version: 0.19.19591 (Git)
Build type: Release
Branch: 3D
Hash: 27771fc6ee93170b6ecb978ff4da438a5b9cfe97
Python version: 3.7.6
Qt version: 5.13.2
Coin version: 4.0.0a
OCC version: 7.3.0
Locale: English/United Kingdom (en_GB)

I am unable to reproduce the bug on this system .

Posted: **Sat Mar 28, 2020 10:29 am**

chrisb wrote: ↑
Sat Mar 28, 2020 9:25 am
And the same test with ProfileEdges ExtraOffset:

export LANG=en_US.utf-8
multiplication by 100

export LANG=de_DE.utf-8 or LANG=de_DE
No multiplication! (see me surprised, almost shocked)

export LANG=en_GB.utf-8
multiplication by 100

Indeed looks like problem with decimal separator. According vocx's early message in this thread, I'd guess the UI isn't using the correct interfaces from the QuantitySpinBox. Spin boxes have valueFromText() and textFromValue() methods that maybe could fix that.

Posted: **Sat Mar 28, 2020 12:00 pm**

Could this be something to do with certain systems not correctly getting locale in FC ?

I do get locale correctly reported in FC Help About and I do see commas and I do NOT see the bug when starting FC in fr_FR locale.

If this was a simple coding error in PropertyDistance I would expect it be consistently visible. Are all those seeing this bug also seeing locale misreported in FC Help menu?

@Chris, what is the normal system wide locale at boot time on your Ubuntu system?

It seems that Unity Ubuntu is Gnome based. I have read that Gnome interferes with the underlying shell mechanism for language/locale settings. I never really got on with Gnome mentality, so I have no direct experience of this.

Posted: **Sat Mar 28, 2020 12:42 pm**

Russ:

The `DepthOffset` and `SampleInterval` properties are handled identically in the getFields() method, but handled much differently in the setFields() method!

QuantityPy.cpp

Code: Select all

    try {
        static_cast<QuantityPy*>(self)->setValue(Py::Float(PyNumber_Float(value),true));
        return 0;

My guess is that thousand sep. commas are stripped out as they are display only convention, not valid in f.p. notation. Incorrect locale detection is leading to comma dec. seps. being removed.

10,00 becomes 1000 .... etc.

Again, are all those seeing this bug also seeing locale misreported in FC Help menu?

Posted: **Sat Mar 28, 2020 6:38 pm**

freman wrote: ↑
Sat Mar 28, 2020 12:42 pm
My guess is that thousand sep. commas are stripped out as they are display only convention, not valid in f.p. notation. Incorrect locale detection is leading to comma dec. seps. being removed.

That's what I would have guessed, but it doesn't explain the factor 10 in the 3DSurface operation. Do you have changes there too?

FreeCAD Forum

[solved] Value increase error: editing 3D Surface changes values all by itself

Re: Value increase error: editing 3D Surface changes values all by itself

Re: Value increase error: editing 3D Surface changes values all by itself

Re: Value increase error: editing 3D Surface changes values all by itself

Re: Value increase error: editing 3D Surface changes values all by itself

Re: Value increase error: editing 3D Surface changes values all by itself

Re: Value increase error: editing 3D Surface changes values all by itself

Re: Value increase error: editing 3D Surface changes values all by itself

Re: Value increase error: editing 3D Surface changes values all by itself

Re: Value increase error: editing 3D Surface changes values all by itself

Re: Value increase error: editing 3D Surface changes values all by itself