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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.
Richard Charney wrote:

Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
ed_1001 wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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)
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
snipped-for-privacy@juno.com wrote:

<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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
ed_1001 wrote:

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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload
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.
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.