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

[chrisb]

This is the topic: https://forum.freecadweb.org/viewtopic. ... 30#p380050
openBrain, uwestoehr, is the issue here connected to the dot vs. comma issue?

ping

ping

[Russ4262]

Evening @ChrisB,.
You are doing a great job of linking topics and searching for solutions,. If I understand the linked topic correctly,. I need to look through the PathWB Gui modules,. and the task panels to which they link,. and identify which type of spin box is being used for these properties that are causing us problems,. Reading the linked topic,. we at least need consistency in usage throughout PathWB,. and better if we can adopt usage in other workbenches,.

This is the topic: https://forum.freecadweb.org/viewtopic. ... 30#p380050

I agree with your other post:

What a mess

On the flip side,. I do feel a spot of relief that the problem wasn't the 3D Surface module code,. explicitly,.

We'll get this sorted out,.

Russ
,.

[Russ4262]

Okay. So, we need some help to take inventory of numerical input boxes in current PathWB operations, dressups, tools, etc.

We need to identify which unit-aware input boxes ARE and ARE NOT affected by this problem. If we can find one or more NOT affected, we can determine how that box is coded and apply that method across the board in PathWB to eliminate this problem.

Are you up for the challenge?

Here's the task:
Open PathWB and a simple model.
Start creating Job(s), operations, dressups, and using other tools that have unit-aware input boxes. Report back if you find one or more unit-aware inputs that are NOT affected by this problem.
Report the name of the input/property and to which operation, tool, dressup, etc... it belongs.
Remember to also post your FreeCAD version information.

Later, we might need to assess the non-unit numerical input boxes as well.

We can do this. Hands in. On @ChrisB's call. One, two three, BREAK!

Russ

[freman]

Russ, I'm guessing this is to do with european countries like FR DE using comma as decimal separator and thousands are the period/fullstop . I had to code some bilingual software once, and untangling this was a bit of a PITA.

To test this probably just requires changing regional settings on the PC. Don't have much to do with Winworld these days but I'd guess on recent Windoze you can set up new user with different regional settings, and thus get comma decimals. Since it seems only the main menu is translated ( at least in French ) it should not be too confusing.

On Linux all locale settings (number format, language,currency) can be altered separately for each login shell, so there is finer control.
eg.
LC_NUMERIC="fr_FR.utf8"

In looking at the Boundary Dressup code, I found that there are input fields which are not standard qt objects. When you open qtDesigner it warns that certain objects are not in the standard library. (That may have been on qt4). I'd be pretty sure that the standard qt objects are not the ones giving trouble: this would have been sorted out years ago if they were. Most likely target is the ones which are homebrewed in FC.

They should inherit the underlying qt objects numeric handling but if someone is poking the text before it gets passed back to locale aware class, that may explain things. Of course , it may not be the object code but just specific input fields where the code is poking around in a non internationalised way.

In the DressupPathBoundary.ui all the numerical inputs are Gui:InputField

That is probably a good place to start. vocx and others have already mentioned boundarybox.

Most reports seem to be german locale, though dubstar is using en_GB ( in mm ). His little vid shows it picking up two extra zeros each time, so maybe not the thousand separator.

A PR I submitted, which got merged recently, changed some properties from PropertyLength to PropertyDistance to allow negative values. eg. StockBoxLength. Maybe there is a difference in how those objects handle numbers.

https://github.com/FreeCAD/FreeCAD/pull/3033

[openBrain]

This is the topic: https://forum.freecadweb.org/viewtopic. ... 30#p380050
openBrain, uwestoehr, is the issue here connected to the dot vs. comma issue?

Hi all. Can't be totally sure but I don't see any obvious reason why it could be directly linked to the QuantitySpinBox implementation. I'd expect to see same problem at many different places if it was the case.

[chrisb]

One, two three, BREAK![/size]

I will add later to this. I will also note other fancy behaviour such as not changing the value immediately after an expression change.

[chrisb]

No change in
- Job->Setup X, Y, Z input boxes; these are not expression aware
- ProfileFaces->Operation->ExtraOffset, also not expression aware
- Contour->Depths, all three values, these are expression aware, but a changed value is not shown before confirm+reedit
- Contour->Heights, the same.

- Most interesting: 3DSurface->Operation->DepthOffset works correctly, directly side by side with the erroneous SampleInterval

[chrisb]

Concerning expression awareness: Am I right that it is not possible to use the same fields as e.g. for pads or pockets, because Path is implemented in Python. So the issues come from the python implementation. I have searched the Draft workbench for an expression aware field, but couldn't find one. The input fields look the same as the correct working fields in Path workbench.

[Russ4262]

Fantastic feedback, ChrisB!
I'm investigating...

No change in
- Job->Setup X, Y, Z input boxes; these are not expression aware
- ProfileFaces->Operation->ExtraOffset, also not expression aware
- Contour->Depths, all three values, these are expression aware, but a changed value is not shown before confirm+reedit
- Contour->Heights, the same.

- Most interesting: 3DSurface->Operation->DepthOffset works correctly, directly side by side with the erroneous SampleInterval

Current list of `Gui::QuantitySpinBox` usage in PathWB task panels is attached.

Gui_QuantitySpinBox List.png (83.89 KiB) Viewed 577 times

Current partial list of `Gui::InputField` usage in PathWB task panels is attached.

Gui_InputField List.png (80.45 KiB) Viewed 572 times

I will look into the results you posted and see how the non-erroneous inputs are coded, both in the task panel and its module Gui file.

Thanks mate,
Russ

[Russ4262]

Eureka!
I think we have something here!

No change in
- Most interesting: 3DSurface->Operation->DepthOffset works correctly, directly side by side with the erroneous SampleInterval

Here is code from PathSurfaceGui.py:

Code: Select all

    def getFields(self, obj):
        '''getFields(obj) ... transfers values from UI to obj's proprties'''
        self.updateToolController(obj, self.form.toolController)
        self.updateCoolant(obj, self.form.coolantController)

        PathGui.updateInputField(obj, 'DepthOffset', self.form.depthOffset)
        PathGui.updateInputField(obj, 'SampleInterval', self.form.sampleInterval)

        if obj.BoundBox != str(self.form.boundBoxSelect.currentText()):
            obj.BoundBox = str(self.form.boundBoxSelect.currentText())

        if obj.ScanType != str(self.form.scanType.currentText()):
            obj.ScanType = str(self.form.scanType.currentText())

        if obj.StepOver != self.form.stepOver.value():
            obj.StepOver = self.form.stepOver.value()

        if obj.LayerMode != str(self.form.layerMode.currentText()):
            obj.LayerMode = str(self.form.layerMode.currentText())

        if obj.CutPattern != str(self.form.cutPattern.currentText()):
            obj.CutPattern = str(self.form.cutPattern.currentText())

        obj.DropCutterExtraOffset.x = FreeCAD.Units.Quantity(self.form.boundBoxExtraOffsetX.text()).Value
        obj.DropCutterExtraOffset.y = FreeCAD.Units.Quantity(self.form.boundBoxExtraOffsetY.text()).Value

        if obj.DropCutterDir != str(self.form.dropCutterDirSelect.currentText()):
            obj.DropCutterDir = str(self.form.dropCutterDirSelect.currentText())

        PathGui.updateInputField(obj, 'DepthOffset', self.form.depthOffset)
        PathGui.updateInputField(obj, 'SampleInterval', self.form.sampleInterval)

        if obj.UseStartPoint != self.form.useStartPoint.isChecked():
            obj.UseStartPoint = self.form.useStartPoint.isChecked()

    def setFields(self, obj):
        '''setFields(obj) ... transfers obj's property values to UI'''
        self.setupToolController(obj, self.form.toolController)
        self.setupCoolant(obj, self.form.coolantController)
        self.selectInComboBox(obj.BoundBox, self.form.boundBoxSelect)
        self.selectInComboBox(obj.ScanType, self.form.scanType)
        self.selectInComboBox(obj.LayerMode, self.form.layerMode)
        self.selectInComboBox(obj.CutPattern, self.form.cutPattern)
        self.form.boundBoxExtraOffsetX.setText(str(obj.DropCutterExtraOffset.x))
        self.form.boundBoxExtraOffsetY.setText(str(obj.DropCutterExtraOffset.y))
        self.selectInComboBox(obj.DropCutterDir, self.form.dropCutterDirSelect)
        self.form.depthOffset.setText(FreeCAD.Units.Quantity(obj.DepthOffset.Value, FreeCAD.Units.Length).UserString)
        self.form.stepOver.setValue(obj.StepOver)
        self.form.sampleInterval.setText(str(obj.SampleInterval))

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

This might be the issue in PathWB.

I'll check some other properties that have been identified as erroneous and report back.

Russ