Body objects and errors in its features

Here's the place for discussion related to coding in FreeCAD, C++ or Python. Design, interfaces and structures.
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Body objects and errors in its features

Post by abdullah »

There is a behaviour of Part Design that I do not like. When a feature in the middle breaks (for example a pad because the sketch after reworking has a non-closed profile or even changing one expression in a spreadsheet that causes an invalid sketch), the body ignores any change on the profile and does not give any feedback (other than the report view).

I am considering these options:
a) When a feature of a body is in error, the body is in error.
b) When a feature of a body is in error, the body still overlays one icon showing that something inside is not ok.

I see pros and contras to both and do not have any strong opinion.

I have made an implementation of b because I wanted to play with extensions again, and make the ViewProviderGroupExtension handle it, it looks like this:
BodyInfo.gif
BodyInfo.gif (497.41 KiB) Viewed 1491 times
As said, no strong opinion, it is not a finished feature, it is a discussion on what is best.
Jee-Bee
Veteran
Posts: 2566
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: Body objects and errors in its features

Post by Jee-Bee »

Why not just breaking the model.
All features that follow on the broken sketch/ feature don't show up?
chrisb
Veteran
Posts: 53920
Joined: Tue Mar 17, 2015 9:14 am

Re: Body objects and errors in its features

Post by chrisb »

Independent from what to display I would like to see the error state generalized: If something is in error, then everything depending on it is in error too. This should hold for sketch-feature-body-part as well as for the constructs from Part workbench.
A Sketcher Lecture with in-depth information is available in English, auf Deutsch, en français, en español.
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Body objects and errors in its features

Post by wmayer »

chrisb wrote: Mon Jul 01, 2019 8:04 pm Independent from what to display I would like to see the error state generalized: If something is in error, then everything depending on it is in error too. This should hold for sketch-feature-body-part as well as for the constructs from Part workbench.
But this makes it harder to find out the root of the problem because you can't easily see any more which feature is causing the actual problem.
Jee-Bee
Veteran
Posts: 2566
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: Body objects and errors in its features

Post by Jee-Bee »

special PartDesign this is easy just the first one.
So for part design i think it is fine to add all resulting errors.
for rest i don't know...
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Body objects and errors in its features

Post by abdullah »

wmayer wrote: Tue Jul 02, 2019 7:13 am But this makes it harder to find out the root of the problem because you can't easily see any more which feature is causing the actual problem.
chrisb wrote: Mon Jul 01, 2019 8:04 pm Independent from what to display I would like to see the error state generalized: If something is in error, then everything depending on it is in error too. This should hold for sketch-feature-body-part as well as for the constructs from Part workbench.
Jee-Bee wrote: Mon Jul 01, 2019 5:22 pm Why not just breaking the model.
All features that follow on the broken sketch/ feature don't show up?
Jee-Bee wrote: Tue Jul 02, 2019 7:55 am special PartDesign this is easy just the first one.
So for part design i think it is fine to add all resulting errors.
for rest i don't know...
There are two points:
(a) what to show in the tree.
(b) what to show in the 3D View.

The current behaviour in the 3D View I think it is the best choice. It still allows to follow the history of the part. If the model broke because a change in a spreadsheet and this value is used in several features, only the one(s) that break are actually shown as in error, while the others adapt to the new value.

For the behaviour on the tree, setting every single feature depending on the broken in error and showing the very same icon (red exclamation on the top right), I think is not the right call. Many of those features marked in error would execute just fine when the broken thing is fixed. I think it is misleading to show the user that the model is fully corrupted and he has to start over again, when something specific just needs to be fixed.

What needs to be somehow marked, IMO, is to show the fact that something in the body is wrong and this most likely mean the body is wrong. This is way I focused on marking the body.

I tend to agree that if something inside is wrong then the body is wrong. What I do not know is if there are cases where the body itself has a red error exclamation sign on the top right for some body related reason and if "my new flag", relating to the features inside, could collide with it.

The reason for choosing a different position/colour could be to differentiate that a feature is broken, and it is not the body itself the reason. But I am extraordinarily open to any colour and position.

I am not sure which other group extensions are there:

Via GeoFeatureGroupExtension:
- App::Part (which is not inherited further)
- PartDesign::Body
- PartDesign::Boolean

Via DocumentObjectGroup:
- Raytracing::LuxProject,
- Fem::FemAnalysis,
- Drawing::FeatureClip,
- Drawing::FeaturePage,
- Inspection::Group,
- Drawing::PageGroup,
- Raytracing::RayProject

I really have no idea how these other classes would like to have the status represented, whether it makes sense or not... anybody?
wmayer
Founder
Posts: 20243
Joined: Thu Feb 19, 2009 10:32 am
Contact:

Re: Body objects and errors in its features

Post by wmayer »

What I do not know is if there are cases where the body itself has a red error exclamation sign on the top right for some body related reason and if "my new flag", relating to the features inside, could collide with it.
According to its execute() method there are two cases where the body itself is broken. The tip points to a non-PD object or the tip points to an empty shape
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Body objects and errors in its features

Post by abdullah »

I have tried my best to generate an error in a FEM Analysis, but I had not been able to.

On the other hand, I have tried in normal groups (DocumentObjectGroup) and this is the result:
Screenshot_20190702_161758.png
Screenshot_20190702_161758.png (32.32 KiB) Viewed 1411 times
Groups, I think, cannot be in error, but may content an item with an error.
abdullah
Veteran
Posts: 4935
Joined: Sun May 04, 2014 3:16 pm
Contact:

Re: Body objects and errors in its features

Post by abdullah »

wmayer wrote: Tue Jul 02, 2019 2:07 pm
What I do not know is if there are cases where the body itself has a red error exclamation sign on the top right for some body related reason and if "my new flag", relating to the features inside, could collide with it.
According to its execute() method there are two cases where the body itself is broken. The tip points to a non-PD object or the tip points to an empty shape
Thanks! It makes sense to look in the right place :)
User avatar
DeepSOIC
Veteran
Posts: 7896
Joined: Fri Aug 29, 2014 12:45 am
Location: used to be Saint-Petersburg, Russia

Re: Body objects and errors in its features

Post by DeepSOIC »

Nice one, Abdullah! These hidden errors have got me at least a few times. I even implemented a check in PoM Exporter feature, that would pop up a message that there is an error anywhere in the dependencies, when exporting.
Post Reply