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

Here's the place for discussion related to CAM/CNC and the development of the Path module.
chrisb
Posts: 24234
Joined: Tue Mar 17, 2015 9:14 am

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

Post by chrisb » Fri Mar 27, 2020 11:56 pm

Good find!
Russ4262
Posts: 427
Joined: Sat Jun 30, 2018 3:22 pm

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

Post by Russ4262 » 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
User avatar
freman
Posts: 951
Joined: Tue Nov 27, 2018 10:30 pm

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

Post by freman » 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.
chrisb
Posts: 24234
Joined: Tue Mar 17, 2015 9:14 am

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

Post by chrisb » 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)
chrisb
Posts: 24234
Joined: Tue Mar 17, 2015 9:14 am

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

Post by chrisb » 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
User avatar
freman
Posts: 951
Joined: Tue Nov 27, 2018 10:30 pm

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

Post by freman » 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 .
Last edited by freman on Sat Mar 28, 2020 12:44 pm, edited 1 time in total.
openBrain
Posts: 3898
Joined: Fri Nov 09, 2018 5:38 pm

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

Post by openBrain » 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.
User avatar
freman
Posts: 951
Joined: Tue Nov 27, 2018 10:30 pm

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

Post by freman » 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.
User avatar
freman
Posts: 951
Joined: Tue Nov 27, 2018 10:30 pm

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

Post by freman » 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?
chrisb
Posts: 24234
Joined: Tue Mar 17, 2015 9:14 am

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

Post by chrisb » 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?
Post Reply

Who is online

Users browsing this forum: No registered users and 1 guest