help locating class definition

[DeepSOIC]

I don't have any problem spinning down Stock's Placement.Position.x into negative. It does not go negative for ExtXpos property you show in the screenshot of the first post. The reason is that it is of type "App::PropertyLength", which is constrained to be non-negative. Change it to "App::PropertyDistance" to have it signed (the names of properties in relation to their signedness are nonsensical, I know... )

[DeepSOIC]

And here's how to locate a class definition.
1.
>>> App.ActiveDocument.Stock.TypeId
'Part::FeaturePython'

=> it's PYTHON, so I know there must be a proxy object, which is where the properties are being created.


2.

>>> App.ActiveDocument.Stock.Proxy.__module__
'PathScripts.PathStock'
>>> import PathScripts.PathStock as PS
>>> PS.__file__
'S:\\_vt\\dev\\PC\\Qt\\FreeCAD\\builds-snapshots\\Default\\Mod\\Path\\PathScripts\\PathStock.py'
>>> App.ActiveDocument.Stock.Proxy
<PathScripts.PathStock.StockFromBase object at 0x0000012ED93E7F60>

Now I know, where to look for the py file, and what class.
=> https://github.com/FreeCAD/FreeCAD/blob ... ock.py#L98
The properties are right in front of me

[freman]

many thanks for such a complete explanation and guide of how to get there. I wish I'd asked before wasting a day bumming around on my own. At least I learnt a fair bit about how the code is laid out which is valuable.

[freman]

At first view that seems to be all that was needed !

Code: Select all

class StockFromBase(Stock):

    def __init__(self, obj, base):
        "Make stock"
        obj.addProperty("App::PropertyLink", "Base", "Base", QtCore.QT_TRANSLATE_NOOP("PathStock", "The base object this stock is derived from"))
        obj.addProperty("App::PropertyDistance", "ExtXneg", "Stock", QtCore.QT_TRANSLATE_NOOP("PathStock", "Extra allowance from part bound box in negative X direction"))
        obj.addProperty("App::PropertyDistance", "ExtXpos", "Stock", QtCore.QT_TRANSLATE_NOOP("PathStock", "Extra allowance from part bound box in positive X direction"))
        obj.addProperty("App::PropertyDistance", "ExtYneg", "Stock", QtCore.QT_TRANSLATE_NOOP("PathStock", "Extra allowance from part bound box in negative Y direction"))
        obj.addProperty("App::PropertyDistance", "ExtYpos", "Stock", QtCore.QT_TRANSLATE_NOOP("PathStock", "Extra allowance from part bound box in positive Y direction"))
        obj.addProperty("App::PropertyDistance", "ExtZneg", "Stock", QtCore.QT_TRANSLATE_NOOP("PathStock", "Extra allowance from part bound box in negative Z direction"))
        obj.addProperty("App::PropertyDistance", "ExtZpos", "Stock", QtCore.QT_TRANSLATE_NOOP("PathStock", "Extra allowance from part bound box in positive Z direction"))

I deleted the old dress-up which was made with pre-modified build and the new one is perfect. I can put in negative extensions. This provides a nice clean solution for simple and non-planar vertical milling ops, using Chrisb's solution of boundaryBox dress-up.

I can understand the limit on PropertyLength, a negative length is a bit like a negative mass. Negative distance works a bit better.

I now see why I was having so much trouble finding the minimum being set to zero

thanks for your help, it's easy when you are looking in the right place .

[chrisb]

The properties are right in front of me

Would you be so kind and have a look at these - hopefully similar fields as well?

Snip macro screenshot-575175.png (17.96 KiB) Viewed 810 times

These are expression-aware fields which behave rather cumbersome: The don't show the correct expression value until the dialog is reopened.

How to reproduce:
- open the attached file
- double click on "Contour" operation
- click on "Depth", now you see the image from above
- edit one of the expressions, e.g. set StartDepth to OpStartDepth+2mm. The correct value of 13mm is shown above the edit field
- confirm with Ok

->issue: the field still shows the old value of 11mm. Editing shows the correct expression and value

- confirming the whole dialog and reopening shows the correct value of 13mm.

[DeepSOIC]

Would you be so kind and have a look at these - hopefully similar fields as well?

this requires much more in-depth exploration, unfortunately. I don't know even how to add an expression button to a python-powered dialog.
All I've found so far is that the fields come from PageDepthsEdit.ui. I don't know how to find that out, other than just looking at all .ui files in Path, and opening ones that may seem related with qt creator/qt designer.

[chrisb]

Thanks for looking anyway.

[freman]

I think where this is happening in the curiously named SurfaceEdit.ui that is the multi-tab dialogue seen when creating and editing tool paths.

PageDepthsEdit.ui uses our old friend QuantitySpinBox.
SurfaceEdit.ui uses Gui::InputField

qt designer shows a warming about these edits being different from the qt internal version and fails to display then. It seems something has been redesigned but uses an existing name. The may be causing a namespace issue and something is not happening as intended.

The file contains a custom widget 'Gui::InputField' whose base class (QLineEdit) differs from the current entry in the widget database (QWidget). The widget database is left unchanged.

Using unique names is better practice when changing a component.

Gui::InputField seems to add the little green tick glyph showing whether the typed input is acceptable input format.