wmayer wrote: ↑Fri Jan 28, 2022 3:38 pm
And when you assign a new shape to an object then its placement will change, too. However, in a feature's execute() function there is a mechanism implemented that checks if the shape is being changed during a recompute and if yes the object's placement is applied to the shape. This is to make sure that object placement and shape placement is equal.
Thanks for deep insight.
However there is still something unclear to me, regarding following snippet :
At the end, shape of the box is still a cube (not a cylinder) but it's now placed at cylinder position...
Of course. When assigning an arbitrary shape to a box feature it gets touched and on the next recompute it will restore its actual shape again. And when assigning the shape outside a recompute the box will accept and keep the placement of the assigned shape.
wmayer wrote: ↑Fri Jan 28, 2022 6:26 pm
Of course. When assigning an arbitrary shape to a box feature it gets touched and on the next recompute it will restore its actual shape again. And when assigning the shape outside a recompute the box will accept and keep the placement of the assigned shape.
All this may sounds obvious for you, and eventually for me after your explanation and having a look at the code.
But IMO from a user PoV, it's somewhat puzzling behavior.
This is not of high importance though. I'll eventually have a look to see if I can propose something around that. And most probably documenting this somewhere could be good, but not trivial.
wmayer wrote: ↑Fri Jan 28, 2022 3:38 pm
So, issue issue #6266 actually isn't a bug but the pitfalls should be documented.
Hi wmayer, where do you suggest this be documented? Also is there a way to identify the pitfall behavior as it's happening and orient the user in an error message in the console?
I have missed this discussion before. The use of "Part::Box" in the examples is actually confusing and obscuring the behavior of the removeSplitter() function IMO. Maybe the question should be: Why does the removeSplitter() function reset the Placement of the shape?
revisiting this issue IMO the problem is that we are allowed to (at least temporarily) assign a value to something that is set as an immutable property, @wmayer is it possible to forbid or reject value assignment for such properties? is it worth doing it or should we just close this issue?
adrianinsaval wrote: ↑Wed Jun 22, 2022 3:24 pm
revisiting this issue IMO the problem is that we are allowed to (at least temporarily) assign a value to something that is set as an immutable property
The Shape property is not supposed to be immutable because there are uses cases where you have a non-parametric feature and want to change it from outside. As an example consider the base class Part::Feature that provides the Shape property but doesn't re-implement the execute() method. Usually you use this feature when importing a shape from a data file (.brep, .step, .iges, ...).
is it worth doing it or should we just close this issue?
wmayer wrote: ↑Fri Jun 24, 2022 9:16 am
The Shape property is not supposed to be immutable because there are uses cases where you have a non-parametric feature and want to change it from outside.
yeah that makes sense, however I get this error when running for example obj.Shape.scale(5)
Traceback (most recent call last):
File "<input>", line 1, in <module>
ReferenceError: This object is immutable, you can not set any attribute or call a non const method
It makes sense for parametric objects but I also get it for a Part simple copy.
are two different things. With the latter the method PropertyPartShape::setPyObject() is called so that it can notify its parent feature class to make sure everything is in sync (like updating the placement) while with the former this won't be possible.
It makes sense for parametric objects but I also get it for a Part simple copy.
This is independent on whether a feature is parametric or not. The only way to do what you want is: