Display States

Does anyone else have problems with Display States being very flaky? I
can set the display of components (hide/show), change to a different
Display State, and when I change back it's anyone's guess as to what
will be displayed. My assemblies are generally quite small (< 20
components). This happens on virtually every assembly. When I open a
drawing, I never know what will be showing in which view. Very
annoying. SW2006SP4.1

 

Yes, have seen this to Ed. It's strange in that it doesn't always do this
for me. Sometimes it's just fine.

Not sure what to make of it.

Richard

 

Does anyone really use them? With their being as nonpredictable as
they are, I certainly can't trust the results. Too bad, they'd be
really useful if they worked.

 

I use them without any of the business you mention. The only time I've
had anything that seemed unpredictable was when I had conflicting
display info assigned in the part, with materials and possibly working
in context. When I cleaned up all of the overlapping
display/color/material/real view overrides, things worked the way they
should.

 

When I first started to use them I had a difficult time deciding if the
display states are flaky, or I am.
After about a half an hour of testing things out while I wrote this, I
think it's a little bit of both

Since I first tried it I found the implementation to be hard to get my
mind around, and the HELP is not as explicit as I would like (for
starters, there isn't even a 'display states' item in the index - what
there is can be found under 'display pane').

Example 1 of confusion/flakiness: the option 'clearing of overrides'
was vague to me. I assumed that it meant the assembly display state for
color would not trump/override the part colors and appearance, but
'delete' or 'remove' or 'return to default' would have been much more
explicit. The thing that made it even harder for me to get is it is
available in the RMB for all of the categories in the display pane,
including color - only just now did I realize now that clear
overrides only (I think) applies to the display mode, and NOT color.
Why not just say so? So I am a bit of a flake for not taking the time
to methodically work out what its supposed to do, and IT's a little
bit flaky for not just telling me what it does in plain english.

Example 2: When I apply color to a subassembly through the display
pane, it gets applied to all of the display states for all of the
configurations. So my question was why have it in display states at
all when it apparently has nothing to do with the display state? Of
course, when writing this I got a hunch and checked - sure enough, in
the 'color and optics' PM there is a collapsed group box at the
very bottom (have to scroll down to even see it) that allows you to
select how your color choice will apply across configs and display
states. One easy to find line in the HELP (or an asterisk next to
'colo'r which lead to a footnote) would have made this
'discoverable' to me, but clearly SWx Help writers are not paid by
the word.

Example 3: I could not figure out how to remove a color applied to a
display state. Turns out that this option is not in the display pane
(which is what I first assumed 'clear overrides meant') It is done
through the 'color and optics' PM, which makes it a few extra
clicks to remove

Example 4: I have mostly used display states across configurations so
components don't change appearance as I flip between configs when
checking the design. So when I made my first display state, I figured
it would be available across all configs - not so. Then I copied and
pasted a state from one config to another, and thought they would be
linked. Nope.
They (apparently are) completely independent. So when I get a state
to where I like it, I have learned to copy and paste that state to all
the configs. It would be cool if I could ctrl+select multiple states
and paste a state into all of them with one click, but it doesn't
seem to work that way. Oh well.

If I had to make a guess (potentially going out on a limb), I would say
that matt has not encountered any flakiness with display states because
he is a very disciplined SWx user that clearly takes the time to really
explore new functions when they come out and root out how they are
supposed to work. I have been an admirer of his deep knowledge of SWx
for the better part of a decade now.

I am not that disciplined with new stuff - I tried it, it behaved in
odd ways, so I gave up in frustration (thanks to my Ed counterpart for
bringing up the topic so I would hit it a little more methodically).

I still don't know if other things cause it to flake out, but at
least I got a handle on some of the odd ins and outs that I didn't
know. Hope this helps someone else in the same, um, state

The other Ed with a 1XX1 after his name (Ed Eaton)

 

<snip>

I haven't used display states to control colors. Generally speaking, I
don't care what color the parts are. I occasionally change a component
color to make it stand out, but this isn't the problem that I have.

I use display states to set up various views of the assembly. In one
view, parts A, B, & C are visible, for example, and all other
components are hidden. Call this display state 1. In display state 2,
parts A, C, D, and E are visible and all others are hidden. Etc.,
etc..

What happens is that after the display states are set up, changing a
visible component to hidden in one display state randomly changes
components in other display states. If you never change anything, it
seems fairly stable. But how real life it that?

Am I using this in a way that wasn't intended? It is the only way that
I know of to have different components visible in different views of a
drawing. Hiding components in the drawing view doesn't work well as
you cannot dimension to a component in a child view if it is hidden in
the parent view. Maybe I'm just missing something. I'm fairly new to
Solidworks (long time UG user), but this just seems to be half baked at
best.

 

I think you're using the way it is intended to be used. Changing the
hide/show or display mode (wireframe/shaded) is definitely how its
intended to be used, changing color less so.

I've not seen this flakiness. I'd be willing to guess there is something
else going on which is causing a conflict.

Maybe you could use a design table to drive it just to make sure.

 

I have tried using them in drawings where I want to make one of say
four items in a pattern transparent to reveal hidden detail. What I
have found there is that it takes the drawing a very noticable amount
of time to actually do the hiding.