Comments on C#er : IMage: Introducing the Visual State Aggregator

I was able to resolve my issues by rebuilding your...

2010-07-16T14:24:54.546-04:00

I was able to resolve my issues by rebuilding your visualstate aggregator into vb.net since i am alot more proficent with vb.net that c#, after i did that I rubuilt your library and it all works.

Thanks Jeremy

Thanks jeremy that is a pretty sweet solution ho...

2010-07-12T12:04:31.122-04:00

Thanks jeremy

that is a pretty sweet solution however when

I tried to change the constructor for the trigger in your VisualAgrregator Source
I now get :

The name 'DesignerProperties' does not exist in the current context

I feel like I am missing something very simple

In the constructor for the trigger, change the cod...

2010-07-09T07:49:55.246-04:00

In the constructor for the trigger, change the code to this:

public VisualStateTrigger()
{
if (!DesignerProperties.IsInDesignTool) {
CompositionInitializer.SatisfyImports(this); }
}

That will make it designer-friendly. :)

I get this error Cannot create an instance of &qu...

2010-07-08T17:17:01.782-04:00

I get this error

Cannot create an instance of "VisualStateSubscriptionBehavior" VSMAggregatorExample

Hi jeremy I am using your visual state aggregator ...

2010-07-08T12:18:15.843-04:00

Hi jeremy I am using your visual state aggregator for a silverlight 4 RIA project and it is working great , the only issue I have is I cannot view the design of any of the XAML pages that usee the visual state aggregator I get errors like :

A value of type 'VisualStateSubscriptionBehavior' cannot be added to a collection or dictionary of type 'BehaviorCollection'.

Any can fire it. Think of this scenario: I have a ...

2010-04-01T00:37:12.485-04:00

Any can fire it. Think of this scenario: I have a panel with a list of customers. When I click on a customer, a panel slides in with the order details for the customer.

There is an event "show detail" that causes the grid to slide away and the panel to slide in. That is two different views and the click command is on the customer list view model, so it publishes "show detail" and the grid "listens" by sliding out of the way and the panel "listens" by coming into focus.

I'm separating the action of grabbing orders, etc, which is straightforward, from the UI element (the slides). My VM doesn't know or care about a grid or a panel or anything else: it simply publishes "show detail" and then we can wire up whatever set of actions we want.

Now on the panel, I *could* have a close action. This is an example where I dirty my view model with a command to facilitate a UI-behavior. Closing has nothing to do with the data, it is a UI activity that says, "I'm done with this." So I can eliminate a command on the view model on instead bind the click of the "close" to the view model event "hide detail". The panel listens by sliding out of view and the grid listens by popping back.

Again, the goal is to separate the UI-specific actions from the view models and have a single event able to coordinate it all.

Are you saying that any of the 3 vms could fire th...

2010-04-01T00:01:46.594-04:00

Are you saying that any of the 3 vms could fire the transition? Or is merely that the transition originates from a single VM but multiple partiers are interested in knowing about it?

I like that idea as well, Glenn. The only issue I ...

2010-03-31T07:31:24.459-04:00

I like that idea as well, Glenn. The only issue I had with that approach is the affinity to the view model. I'm looking at a state transition that possibly coordinates between multiple views/controls and they each might have their own VM, so which VM would "own" the state property? All three? This way allows the various fews to subscribe to the state change regardless of their VM affinity, and allows any VM to publish the state change.

Interesting approach Jeremy. One question I have i...

2010-03-31T01:55:44.807-04:00

Interesting approach Jeremy. One question I have is why not just have a State property on your VM which throws a PropertyChanged notification when it is changed, and then have an attached behavior that litens to the State property change and then moves the VM state accordingly?

Glenn

I can't say I agree here. Yes, there is, in my...

2010-03-19T07:36:07.019-04:00

I can't say I agree here. Yes, there is, in my opinion, an unwarranted obsession with "no code behind" (let's face it, XAML is code, albeit a different way to represent it). However, I believe VSM is intended for transitions and states, and the it is more convuluted to change the design of a view model simply to accommodate an animation when you can keep it all in the UI.

Changing a state when a service call completes or business logic fires is one thing ... then it makes sense to have a delegate or other mechanism to fire off an animation ... but if it is truly for transitions based on events, I don't see any valid reason to involve more layers than necessary.

This looks interesting. But I agree with your sus...

2010-03-19T06:21:27.793-04:00

This looks interesting. But I agree with your suspicion that you are overloading the vm's responsibility.

I think the obsession with zero code behind creates some very convoluted implementations. Personally I accept that an animation is a job for the view, sometimes it can't be managed / created in xaml, so just do it in the code behind. job done.