I agree with you. SP1.0 added the ability to decrease the
amount of space Display States takes up but we still can't get rid
of it completely. I've also noted that it doesn't stay minimized
and tends to enlarge itself and cover configurations.

I think Display States can replace the use of Configurations in
some applications. At this point I have very little use for Display
States, it can't replace my use of configurations and ties up space
on my feature manager. I want a check box to get rid of it the 95%
of the time I have no use for it.

I fully agree. Display states will not replace configurations
for our purposes.
More often than not we have the tab for configs open at the top and
the feature manager tab open below it. Everytime the view returns
to the assembly the display states bar grabs all the room in the
configs tab.
If it cannot be turned off can it at least default to the smallest
view possible. If the option for "Link Display states to
Configurations" is selected there is only 1 line in it anyway, at
least it could compress to this 1 line.
I think this is just sloppy programming, not an intentional
feature.

There has been a bug in 2008 that's supposed to be fixed in
SP4 where the display states manager covers up the configurations.
It also seems to help if you toggle OFF the option to link display
states to configurations if you don't update SPs regularly

Please for the love of God...
SW, Just get rid of Display States alltogether...
Or at least make a setting to completely disable them...
Even with that portion of the tree hidden down.. The Display State
name makes the Configuration tree soooooo long!!!
At a Minimum.. just let User's Hide the display State name that's
taking up so much space in the configuration tree...

Seems like if you have "Link DS to Config" unchecked.....it
shouldn't even show it next to the configuration name since its the
same for all configs anyway. That setting is really just legacy
support for the way Disaply States worked prior to 2008.....when we
use Display States, we now uncheck that option.

Display states have their use and they are incredibly fast compared
to configurations. We have large assembly with many configs that
can now use Display States. Only two things are needed to really
make it useful. Multiple Exploded views for one config......and the
ability to set the display state of an assembly from a parent
assembly.

On Mine,
It doesn't make any difference whether the "Link Display States to
Configuration" is Checked or Unchecked.. the Display State name is
always in the Configuration name....
It just makes the name soo long..
The tree would fill half the screen if i moved it out to where the
entire "name" was visible.

What's the goal of even having Dispay States?
Isn't that what Configurations are for?
Why Both? It's just double the trouble?
Did some Bonehead have a brain fart coming up with this crap?
It's just a Broken pita..

Display State might actually be somewhat useful if you could
supress/Control Explode steps with it...
Dumb Q, but what is the Purpose of it(DS) anyway? Maybe I'm missing
some point somewhere... But i just can't figure out what it's even
for...
Yes, i know it can control part visibility.. But it Can't control
Explode steps...
Config's you can control visibility and change around Explodes....
So that's what the use??

Display States are lighter than Configs. Its more like a view
filtering tool.

We use them for creating different views of the assy with parts
hidden to show just a group. Like assembly steps, of course only
only one explode per config is a problem but it was on the top ten
list so maybe 2009.

I know you can do this with configs as well but its much slower and
is messier when you need a lot of configs. For us, configs
represent part numbers so its nicer having a separate lighter tool
for just filtering views of the model.

I mainly use Configs for creating Assembly manuals of
applicable assemblies...
Config 1 would be "Setp 1", and so on... And Each Step (Config) has
it's own Exp View Sshowing All parts assembled up to the current
step.. and All parts in steps forward are hidden... Know what i
mean...
Which the actual individual Explode distances, etc.. are the same
as the Complete assemblies Explode.. So if Display States could
control the explode steps.. i could do the entire thing using a
single Explode View.. and just have certain Steps supressed to show
partial assembly...
I'd submit an ER for this... but I can't Find Display States
anywhere in the ER page...

As far as part visibility in drawings... I control that in the
Drawing view directly...

Yeah, thats the way we've been doing it as well....and we
still do in some cases because of the exploded view limitiations.
If they add the ability to get multiple explodes going for one
config, the Disaply states will really work well.

We do the same for drawings sometimes hiding in the parts in the
view but only for cases where we need to hide a small amount of
parts. Gets hard to manage otherwise.

Usually what we have are large assemblies where we need to show
several drawing views of groups of sub components. We've always
used configurations but display states are faster and I'm leaning
that way now. Then I don't have to worry about whether the part
number and descriptions (and other properties) for all the configs
are right which is a problem now. Derived configs can help some
with this though.

We also use configs to represent families of parts so display
states help distinguish the configs(parts) from DS(view filters).

I've always wondered why we can't have more than 1 Explode
per config...

Also, When the assembly i'm working on is larger... I Supress
components that are hidden.. rather than just Hiding.... that makes
overall operation much faster..
Switching between Configs is actually Lot faster than switching
between display states that are set up to show/hide same items in
single config...