Visual States in XAML Templates

re: Visual States in XAML Templates

joewood — Tue, 27 May 2008 23:56:21 GMT

"the condition we left the control code itself".

Is that (or could that) be via an attached behavior? Or do you mean for each state property there will be a storyboard property that is fired when the value changes?

Dog Breeding » Visual States in XAML Templates

Dog Breeding » Visual States in XAML Templates — Wed, 28 May 2008 00:32:59 GMT

PingBack from http://dogs-pets.info/dog-breeding/?p=970

re: Visual States in XAML Templates

JohnGossman — Wed, 28 May 2008 03:03:50 GMT

The condition could be an attached behavior...though in Silverlight it generally isn't.

re: Visual States in XAML Templates

JoeS — Thu, 05 Jun 2008 21:19:18 GMT

I've seen some of the recent blogs from some ms people talking about the upcoming release of silverlight beta 2. While I can say I look forward to a lot of things you have added/addressed, the whole concept of a visual state manager seems like a hack to me. So first we had the parts model, which I assume is still there, now we have a visual state manager, in wpf we have triggers, where will this end? Is it the end of the way we template controls in WPF? Will the VSM be the preferred way in WPF and Silverlight? Are there now going to be 4 things to think about when designing controls in both frameworks, Triggers, VSM, Parts Model, Transitions? Are you guys planning to introduce more new ways to do this kind of stuff in V next? I still don't understand what was wrong with how it was done in WPF and why not try to keep to one model. How you do not plan to have a basic WPF feature like triggers in a so called subset of WPF is beyond me, but hey, I understand some things just are not possible and need to be cut. This would have been on the top of my list from the start though. Anyway, I'm not trying to be a downer on Silverlight, I'm actually very interested in it. My concern is with code reuse and maintenance. It's great that Silverlight and WPF both use .Net and in that it is great and easy for people to jump back and forth, but when you have all of these ways to do the same things when it comes down to controls, it just seems unnecessary and confusing, especially people new to WPF/Silverlight.

VisualStateManager

Tales from the Smart Client — Wed, 11 Jun 2008 01:33:28 GMT

Recently , I talked about how templates in WPF/SL are fundamentally built around the concept of a state

re: Visual States in XAML Templates

Neil Mosafi — Thu, 19 Jun 2008 00:16:12 GMT

Fantastic, I just stumbled across this blog post and it answers a lot of the questions I had around this unification of templating in WPF and XAML.

Ignore the complaints! People forget that WPF and especially Silverlight are still in early development and are basically at v1. Templating controls in WPF can become very complicated and it's not at all "intention revealing" when you read a template with 10s of triggers all combined with multitriggers etc. Triggers->Named States Changes->Visual Tree Changes makes complete sense to me! You have the right to change the model, especially when it simplifies things.

So I assume that this is the way you will do state transitions in DataTemplates in Silverlight?

VisualStateManager for desktop WPF

Tales from the Smart Client — Sat, 09 Aug 2008 01:31:41 GMT

As I’ve described before , we introduced the new VisualStateManager concept into Silverlight WPF before

Resources for Control "Skinning" with VSM - VisualStateManager

WPF, Silverlight and .NET Musings — Fri, 19 Sep 2008 06:40:22 GMT

VisualStateManager, a.k.a. VSM, I quote our WPF architect John Gossman's words from the architectural