A little bit confused about VisualStateManger in WPF4/3.5 and Silverlight

[Corrado Cavalli]

All I need to do is move a button from point A to point B inside a Window or UserControl, using Blend I can generate the same XAML:

 

                <Grid x:Name="LayoutRoot">

                               <VisualStateManager.VisualStateGroups>

                                               <VisualStateGroup x:Name="States">

                                                               <VisualState x:Name="Normal"/>

                                                               <VisualState x:Name="Moved">

                <cut…>

 

In SL to move the button I can use: VisualStateManager.GotoState(this, “Moved”,true)

In WPF4 to do the same I need to use: VisualStateManager.GoToElementState(LayoutRoot,"Moved",true);

In WPF3.5 I need to use GotoStateAction otherwise can’t find a way to move it (Grid isn’t a FrameworkElement)

 

Getting a bit lost, why can’t we use the same code?

 

-Corrado

 

 

 

[Mark Smith]

Hi Corrado,

I suspect you are running into a bit of evolutionary growth.  I don't know the inside story, but here's what I surmise after using VSM with all three technologies to date.  

VSM was created as a semi-replacement for control template triggers for Silverlight, that's why the GotoState takes a Control as it's first parameter- because it was assumed the visual states would be defined in a control template.  But I assume as they pushed it into the WPF toolkit it soon became clear that it could also be used as a general purpose animation state manager as well, so the concept of a custom visual state manager was added to allow people to extend VSM without changing the primary API used by control templates. 

When you use the GotoState action in Blend, it also adds a CustomVisualStateManager of type "ExtendedVisualStateManager" that lives in the Microsoft.Expression.Interactions.DLL.  This class extends the normal VSM and allows you to pass in a FrameworkElement and transition state off that (making it far more broad).  The GotoStateAction.Invoke code relies on this and attempts to cast the target to a Control and then if that fails, uses the ExtendedVisualStateManager.GotoElementState static method.

This feature is very useful and so it looks like it's been mainstreamed into WPF4 - that's where the new GotoElementState method came from.  With that in place in WPF4, we no longer need the ExtendedVisualStateManager since we can directly target FrameworkElements with the new method.

But this is a bit painful on the compatibility side as you've noted.  WPF 3.5's implementation (in WPF Toolkit) doesn't have the feature and requires the Blend ExtendedVSM code to work.  So for WPF 3.5 you could add Microsoft.Expression.Interactions.dll and then call ExtendedVisualStateManager.GotoElementState yourself in your code and in WPF4 use the new method.  A bit clunky but it should work.

mark

[Corrado Cavalli]

Hi Mark,

Brilliant analysis.

 

.Corrado

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Mark Smith
Sent: domenica 20 dicembre 2009 23:53
To: wpf-di...@googlegroups.com
Subject: Re: [WPF Disciples] A little bit confused about VisualStateManger in WPF4/3.5 and Silverlight

 

Hi Corrado,

I suspect you are running into a bit of evolutionary growth.  I don't know the inside story, but here's what I surmise after using VSM with all three technologies to date.  

 

VSM was created as a semi-replacement for control template triggers for Silverlight, that's why the GotoState takes a Control as it's first parameter- because it was assumed the visual states would be defined in a control template.  But I assume as they pushed it into the WPF toolkit it soon became clear that it could also be used as a general purpose animation state manager as well, so the concept of a custom visual state manager was added to allow people to extend VSM without changing the primary API used by control templates. 

 

When you use the GotoState action in Blend, it also adds a CustomVisualStateManager of type "ExtendedVisualStateManager" that lives in the Microsoft.Expression.Interactions.DLL.  This class extends the normal VSM and allows you to pass in a FrameworkElement and transition state off that (making it far more broad).  The GotoStateAction.Invoke code relies on this and attempts to cast the target to a Control and then if that fails, uses the ExtendedVisualStateManager.GotoElementState static method.

 

This feature is very useful and so it looks like it's been mainstreamed into WPF4 - that's where the new GotoElementState method came from.  With that in place in WPF4, we no longer need the ExtendedVisualStateManager since we can directly target FrameworkElements with the new method.

 

But this is a bit painful on the compatibility side as you've noted.  WPF 3.5's implementation (in WPF Toolkit) doesn't have the feature and requires the Blend ExtendedVSM code to work.  So for WPF 3.5 you could add Microsoft.Expression.Interactions.dll and then call ExtendedVisualStateManager.GotoElementState yourself in your code and in WPF4 use the new method.  A bit clunky but it should work.

 

mark

 

On Dec 20, 2009, at 9:26 AM, Corrado Cavalli wrote:

[John Gossman]

Pretty much how it went.  The Blend team invented VSM.  It was far less work and had a better tooling story than Triggers and we were under enormous time pressure in SL2, so we implemented it there first.  The Blend design always had more functionality than we could get into SL2 at the time so we added the CustomVisualStateManager so we could add the other behavior out of band (ironically, the Blend guys originally told me they didn't think they would use the customization...I insisted we put it in anyway simply so we could keep prototyping and it paid off).  Over time we will add the extended behavior into the base *and* probably add more extended behavior as we get it. 

Compilers and graphics are science.  This UI Framework design thing is more like pottery or basket weaving.

[Josh Smith]

I'm intrigued by that last sentence, John.  Please elaborate...

[Evan Lang]

I suppose compilers and graphics-oriented code can be valued more quantitatively, with lots of effort put into complex algorithms that have a definite “right” outcome.  UI framework design is more qualitative, with much fewer, much simpler algorithms, but more difficult subjective architectural decisions to make.

 

It’s not a black and white distinction by any means; BNFs and scene graphs definitely have their use cases and usability issues to worry about, and UI frameworks definitely have their performance and logic issues. But the analogy makes sense to me.

 

From: wpf-di...@googlegroups.com [mailto:wpf-di...@googlegroups.com] On Behalf Of Josh Smith
Sent: Tuesday, December 22, 2009 9:59 AM
To: wpf-di...@googlegroups.com
Subject: Re: [WPF Disciples] A little bit confused about VisualStateManger in WPF4/3.5 and Silverlight

 

I'm intrigued by that last sentence, John.  Please elaborate...

[John Gossman]

What Evan said.  There is also something where intuition and opinion seem to be less important in graphics for example.  A lot of graphics work is done by one guy working through and "solving" a problem and everybody pretty much agrees that their solution is correct (this is the result, not necessarily the implementing code which may be very idiosyncratic).  Whereas even when we're done with something like VSM we're not sure whether it is right or wrong or even what right and wrong mean.