Home/ Questions/Q 9311191
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-19T01:18:09+00:00

I have written a custom control. I currently have several control templates that all

  • 0

I have written a custom control. I currently have several control templates that all duplicate a lot of triggers for showing/hiding stuff etc. I am trying to move some of this functionality into the control itself to tidy up the templates a bit, and have been reading up on control parts, and the visual state manager.

Currently the control exposes a property eg IsExtraInfoShown. The control templates all have their own triggers on this property to show/hide the appropriate areas.

After reading about control parts, this seems to fit perfectly. All the templates have a named PART_ExtraInfo, and the control shows/hides this as appropriate.

But then I read about the visual state manager, which seems to infer I should create an ExtraInfoVisibility group, and have InfoShown and InfoHidden states that the templates can define, and editors like Blend can operate on.

Which should I use? Or is possible to use both? Ie, I hide/show PART_ExtraInfo if it’s there, and if not I GotoState()?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It appears that when using the VisualStateManager it is assumed that your also following the parts and states model. In this case the name really says it all. If that’s not enough, use of defined parts along with states by tutorials on the web regarding the VisualStateManger hits it home that the not only are parts still relevant when using states but they become even more useful since they specify the elements that will be used by the control in order to determine state. See Parts & States model with VisualStateManager (part 3 of 4) for more details on how.

    In terms of the overlap between traditional ways of setting visual state such as with triggers or code within event handlers and the parts and states model, the advice seems to be that once you use states to manage the visual concepts defined within the state groups that you should refrain from using triggers or direct setting of code to manipulate these values otherwise.

    If you want a good read on the concerns about how to integrate the VisualStateManager in WPF along with existing techniques that we have become comfortable with I recommend reading over the pots The VisualStateManager and Triggers by Carole Snyder. That article has an interesting quote which helped me with some of the questions I’ve had regarding.

    Control authors should continue to define properties for visual states
    even when they use the VisualStateManager to transition between their
    visual states.

    • 0