0003518: Expressions (fx) not updated

[amrit3701]

Hello everyone,

I have submitted an on FreeCAD bug tracker a week ago: https://www.freecadweb.org/tracker/view.php?id=3518

Issue description:
When I try to merge a parametric object in a new document, its expressions are not updated. For eg. suppose we have a parametric object which has an expression "object.Length.Value". And when I try to merge this object in some document which already have some objects, the newly merge object named as "object001" but its expression remains the same (i.e "object.Length.Value"). I expected that newly expression should changed as "object001.Length.Value".

Now, I am working on this issue but please guide me, where is the code related to expression present in the FreeCAD source code.

Thanks,

[eivindkvedalen]

Hello everyone,

I have submitted an on FreeCAD bug tracker a week ago: https://www.freecadweb.org/tracker/view.php?id=3518

Issue description:
When I try to merge a parametric object in a new document, its expressions are not updated. For eg. suppose we have a parametric object which has an expression "object.Length.Value". And when I try to merge this object in some document which already have some objects, the newly merge object named as "object001" but its expression remains the same (i.e "object.Length.Value"). I expected that newly expression should changed as "object001.Length.Value".

Now, I am working on this issue but please guide me, where is the code related to expression present in the FreeCAD source code.

Thank you for looking into this issue; I have had too little time to work on FreeCAD lately.

Every DocumentObject has an ExpressionEngine property, and this property keeps all expressions entered into a DocumentObject. In the merge function, you need to visit each expression and rename objects that are referenced there.

Relevant source code files are:
App/DocumentObject.{cpp,h} (contains the ExpressionEngine property)
App/Expression.{cpp,h}
App/ExpressionVisitors.{cpp,h} (contains renaming visitors; most likely relevant for you, either directly or as inspiration).

Eivind

[DeepSOIC]

Actually, I wouldn't consider it a bug.

object.Length.Value, from your description, appears to be a self-reference. When self-referencing, I would use Length.Value, i.e. drop the object name. Since you explicitly specified the object name in the expression, if I were ExpressionEngine, I would assume that you mean "object named 'object' and nothing else".

BTW...
Expression object.Length.Value is strange, I've never seen such an expression. Particularly the .Value part of it. Could you explain, what Length property has a subproperty?

[ulrich1a]

BTW...
Expression object.Length.Value is strange, I've never seen such an expression. Particularly the .Value part of it. Could you explain, what Length property has a subproperty?

The subproperty was coded in the quantity object, in order to allow a transition from python code before existance of quantity to FreeCAD with quantity. The subproperty Value supplies the pure number without unit string. This is what I remember from python coding.

Ulrich

[amrit3701]

Actually, I wouldn't consider it a bug.

object.Length.Value, from your description, appears to be a self-reference. When self-referencing, I would use Length.Value, i.e. drop the object name. Since you explicitly specified the object name in the expression, if I were ExpressionEngine, I would assume that you mean "object named 'object' and nothing else".

BTW...
Expression object.Length.Value is strange, I've never seen such an expression. Particularly the .Value part of it. Could you explain, what Length property has a subproperty?

Here Length property belongs to App::PropertyLength.

Let me explain with some example.
Suppose, I have two objects (Cone and Box) in a document (testingexp.fcstd). The length, width, and height of Box depend on Cone height.

Code: Select all

>>> obj = App.getDocument("testingexp").getObject("Box")
>>> obj.ExpressionEngine
[('Height', 'Cone.Height'), ('Width', 'Cone.Height'), ('Length', 'Cone.Height')]

In the new document (after_merging_testingexp_two_times.fcstd), I merge testingexp.fcstd two times and the new document has now four objects (i.e Box, Cone, Box001, and Cone001). Both the Box and Box001 linked with one Cone. I expected that Box001 should be linked with Cone001.

Code: Select all

>>> obj = App.getDocument("Unnamed").getObject("Box")
>>> obj.ExpressionEngine
[('Height', 'Cone.Height'), ('Width', 'Cone.Height'), ('Length', 'Cone.Height')]
>>> obj = App.getDocument("Unnamed").getObject("Box001")
>>> obj.ExpressionEngine
[('Height', 'Cone.Height'), ('Width', 'Cone.Height'), ('Length', 'Cone.Height')]

Thanks,

[DeepSOIC]

I merge testingexp.fcstd two times and the new document has now four objects (i.e Box, Cone, Box001, and Cone001). Both the Box and Box001 linked with one Cone. I expected that Box001 should be linked with Cone001.

OK, thanks for clearing it up. It's not a self-reference, and indeed a bug.

[chrisb]

For my taste that is at the border of things I want to happen automatically.

In your example you use the internally created names of objects. That this leads to problems, if you merge some of them into another model where the same names are used seems to be obvious. If you rename your object to something sensible and refer in the expression to that notion you have no problem keeping the references when copying.

Instead of remapping things I would prefer to mark the objects and tell the user via error messages that references have to be looked after.