[solved] Value increase error: editing 3D Surface changes values all by itself
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Value increase error: editing 3D Surface changes values all by itself
Good find!
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Value increase error: editing 3D Surface changes values all by itself
Evening Ladies and Gentlemen,
I was just looking over the data submitted and some additional details caught my eye.
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:
Russell
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:. In the split PR, I applied this method to SampleInterval and BoundBoxExtraOffset.
Code: Select all
self.form.extraOffset.setText(FreeCAD.Units.Quantity(obj.OffsetExtra.Value, FreeCAD.Units.Length).UserString)
- 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)
Russell
Re: Value increase error: editing 3D Surface changes values all by itself
Good work Russ.Each of the properties mentioned above are of the type `App::PropertyDistance`.
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.
Re: Value increase error: editing 3D Surface changes values all by itself
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)
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)
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Value increase error: editing 3D Surface changes values all by itself
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
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
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
Re: Value increase error: editing 3D Surface changes values all by itself
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]
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)
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 .
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 .
Last edited by freman on Sat Mar 28, 2020 12:44 pm, edited 1 time in total.
Re: Value increase error: editing 3D Surface changes values all by itself
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.
Re: Value increase error: editing 3D Surface changes values all by itself
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.
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.
Re: Value increase error: editing 3D Surface changes values all by itself
Russ:
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?
QuantityPy.cppThe `DepthOffset` and `SampleInterval` properties are handled identically in the getFields() method, but handled much differently in the setFields() method!
Code: Select all
try {
static_cast<QuantityPy*>(self)->setValue(Py::Float(PyNumber_Float(value),true));
return 0;
10,00 becomes 1000 .... etc.
Again, are all those seeing this bug also seeing locale misreported in FC Help menu?
Re: Value increase error: editing 3D Surface changes values all by itself
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?
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.