Component Visibility Passed On To Part's Internal Working Geometry

[lennart_mueller-wirts]

There is an issue for years now, that we need to be fixed (at least for us it is a massive issue, that we cannot see any upside in the current way of implementation).

Description

Suppose you got an assembly with a part containing work geometry. Now by whatever reason (better oversight, show someone what's behind, ...) you want to temporarily make it invisible - so you select the part and uncheck visibility (or press Alt + V).

Then, when you want to unhide it, the visibility is somehow passed on to all working geometry and also some sketches inside that part.

Workaround(s)

You can work around that by explicitly defining another View Representation to be used inside the assembly at hand - but as long as the (locked) default "Primary" is selected, this behaviour remains...

When you now switch to the part using "Open", the view representation "Primary" has somehow infered the checked visibility status from our assembly, which undesiredly means, that all other instances of the part anywhere else (incorporating the standard "Primary" view rep by default) now show all their work geometry and sketches...

What you can do now is uncheck visibility for each child now and save, what sometimes solves the issue. BUT: this is an absolute hassle and not how it's supposed to be.

Steps To Reproduce

0.1 Create a part containing work geometry.

0.2 Create an assembly and add the part [working geometry]

1. Hide the part inside the assembly

2. Unhide the part by checking "Visibility"

Now: somehow all working geometry and unused sketches are visible (which they should not be).

Expected Behaviour

When visibility is re-checked, the former state should be restored.

(Even loading the part's actual "Primary" state would be better than the current behaviour - as of now, it makes all entities visibible and overwrites "Primary" state by that...)

Assumption

This is a bug.

Something is wrong with the initialization of the default state for a new part's view rep "Primary".   

It just can't be the desired way this has been designed.

Some More Thoughts In This Regard

Actually: why can't we even...

1. ...see View Reps of sub-parts in the assembly's model tree (with an option to hide these via the burger menu in the mnodel tree's top right)?

2. ...reference the "Primary" view rep "associatively" (for "Primary" the checkbox is greyed out)?

3. ...unlock the view rep "Primary" if desired?

We cannot see any advantages in this behaviour and would love to get rid of it. So please fix! _/\_

[johnsonshiue]

Hi! I could be wrong, but I think this has something to do with Design View Rep management. I assume the part you created on Step 0 was created in place from scratch, not inserted. When you changed the visibility of the part workplanes, it was also done in the assembly, not within the part itself (open in its own window).

There is a subtle behavioral difference in terms of Design View Rep. When it is done in an assembly, the change only applies to the work geometry in the context (of the assembly). It does not persist back to the part file itself. Then you make the invisible part visible, and the visibility state go back to as if the part is freshly inserted (honoring the visibility state in the part).

It would be nicer if we reverted back to the visibility state before you make the in context visibility change. If you factor in Undo plus context switching is allowed (n-level deep), the behavioral model will become unmanageable fairly quickly.

The current behaviors are not ideal for sure. It is confusing and hard to understand. But we don't have a good solution to make it nicer without breaking other behaviors unfortunately.

Many thanks!

[lennart_mueller-wirts]

Thanks for your reply @johnsonshiue 🙂

The part was being created just as usual, selecting "New → Part → Standard" and afterwards inserted into an assembly - actually, this particular assembly shown above was only created to showcase exactly this behaviour to you...

I do not think that this can be the expected or desired way... 🫤

Quick Fix Solution: Just preventing the passing-on of the freshly re-activated visibility state from the part inside the assembly to its own children that are working geometry/sketches would make up for a sufficient quick fix.

Better Solution: Most intuitive solution would be: cache the (internal) visibility state of the part inside the assembly when it gets hidden and restore that locally chached state when visibility is re-enabled (if no other associative view-rep is being activated). Even copying what's inside the locked "Primary" state from the part itself (still don't understand why it can not be unlocked) would be better than it currently is...

Current Workaround: I make use of a rather complicated iLogic-rule that recursively goes through all sub-parts and sub-assemblies, creating a new view rep "Standard" there, activate it and uncheck all visibility states for the unwanted entities for it. If you're interested in that, you may find it attached here.