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.
abdullah
Posts: 3174
Joined: Sun May 04, 2014 3:16 pm

Body objects and errors in its features

Postby abdullah » Mon Jul 01, 2019 4:44 pm

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 243 times
As said, no strong opinion, it is not a finished feature, it is a discussion on what is best.
Jee-Bee
Posts: 1921
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: Body objects and errors in its features

Postby Jee-Bee » 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?
chrisb
Posts: 16932
Joined: Tue Mar 17, 2015 9:14 am

Re: Body objects and errors in its features

Postby chrisb » 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.
wmayer
Site Admin
Posts: 14478
Joined: Thu Feb 19, 2009 10:32 am

Re: Body objects and errors in its features

Postby wmayer » Tue Jul 02, 2019 7:13 am

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
Posts: 1921
Joined: Tue Jun 16, 2015 10:32 am
Location: Netherlands

Re: Body objects and errors in its features

Postby Jee-Bee » 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...
abdullah
Posts: 3174
Joined: Sun May 04, 2014 3:16 pm

Re: Body objects and errors in its features

Postby abdullah » Tue Jul 02, 2019 12:27 pm

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
Site Admin
Posts: 14478
Joined: Thu Feb 19, 2009 10:32 am

Re: Body objects and errors in its features

Postby wmayer » 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
abdullah
Posts: 3174
Joined: Sun May 04, 2014 3:16 pm

Re: Body objects and errors in its features

Postby abdullah » Tue Jul 02, 2019 2:21 pm

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 163 times
Groups, I think, cannot be in error, but may content an item with an error.
abdullah
Posts: 3174
Joined: Sun May 04, 2014 3:16 pm

Re: Body objects and errors in its features

Postby abdullah » Tue Jul 02, 2019 2:25 pm

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
Posts: 6688
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Body objects and errors in its features

Postby DeepSOIC » Tue Jul 02, 2019 2:35 pm

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.