New post AttachedCommandBehavior or as I call it ACB

2,262 views
Skip to first unread message

Marlon Grech

unread,
Dec 4, 2008, 4:30:52 PM12/4/08
to wpf-di...@googlegroups.com
Hey guys,

I wrote a new post on Commands. This time it is a prototype of how one can hook a Command to any Event in a control.
http://marlongrech.wordpress.com/2008/12/04/attachedcommandbehavior-aka-acb/

Feedback is always welcome :)

Hope you like it....

Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/

Bill Kempf

unread,
Dec 4, 2008, 4:44:58 PM12/4/08
to wpf-di...@googlegroups.com
Looks very interesting. I'm going to have to read the whole thing
closely, but after skimming over some of the intro stuff, there's at
least one apparent drawback to the current design: you can only use
this on a single event. To support multiple events, you'd probably
need a read-only collection property that uses the lazy instantiation
trick Mr. Gossman enlightened us to. Eventually, this would flesh out
to be quite similar to the "ActionMessages" concept you find in
Caliburn (http://devlicio.us/blogs/rob_eisenberg/archive/2008/01/09/caliburn-using-actionmessages-to-enable-mvc-in-wpf.aspx).
I've gone down the route of trying to refine this to my liking a few
times, and each time the biggest roadblock was the lazy initialization
of the collection. Now that I know how to do that, I could go back
and revisit some of my last attempts. If being able to work with
multiple events is a concern for you, you might want to also take a
look at Caliburn for inspiration in this area as well. All of these
concepts are similar, with different design choices and trade-offs.

Now, back to reading this blog post for more details :).

--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.

War is peace. Freedom is slavery. Bugs are features.

Marlon Grech

unread,
Dec 4, 2008, 4:49:12 PM12/4/08
to wpf-di...@googlegroups.com
Yea that is in fact a limitation.... mmm interesting... I can add this quite easily in my solution :)

I think you just started the fire for my next post.... OW BILL.... you screwed my weekend !!!! LOL


Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/



Peter O'Hanlon

unread,
Dec 4, 2008, 4:54:35 PM12/4/08
to wpf-di...@googlegroups.com
I'd like to see that, although the single Event isn't too much of a limitation and I can come up with several practical implementations for this - so I'll be looking to see where I can hook this into. Damn, but this WPF stuff is so extensible.
--
Peter O'Hanlon

Bill Kempf

unread,
Dec 4, 2008, 4:59:04 PM12/4/08
to wpf-di...@googlegroups.com
LOL. Weekend? I've been hacking at various solutions to this sort of
thing off and on for going on 2 years now. ;)

Thanks to Mr. Gossman's lazy initialization for read-only attached
properties, I could finally get around to mostly burying this concept
with an "almost optimal" design, if I had the time to work on this
again. However, I don't have the time right now, and I'm still hoping
Microsoft addresses the real issue in all of this: I can't specify an
event handler from any object but "this" (meaning it must be in the
code behind). If I could just do this:

<Button Click="{EventHandler Source={StaticResource ViewModel},
Handler=ClickHandler}">Click me!</Button>

Where Source would default to the DataContext if not supplied, so
MVPoo scenarios could be simplified to:

<Button Click="{EventHandler ClickHandler}">Click me!</Button>

Then allow me to do the same with a CommandBinding. Or some other
syntax. What ever. Just let me specify event handlers outside of the
code behind! :)

Marlon Grech

unread,
Dec 4, 2008, 5:07:12 PM12/4/08
to wpf-di...@googlegroups.com
Well I see command fitting in quite well for this... This is one reason why I created the ACB... no more codebehind....


Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/



Bill Kempf

unread,
Dec 4, 2008, 5:19:30 PM12/4/08
to wpf-di...@googlegroups.com
Hrmmm... I'll have to disagree, at least slightly. Commands imply, to
me at least, CanExecute functionality. Once we extend this idea to
embrace multiple events, CanExecute functionality starts to become a
little murky, at best. Without CanExecute, you may just as well be
dealing with a delegate instead of an ICommand. You're already doing
reflection here, so like Caliburn did with ActionMessages, you could
remove the need for defining a command and hook up the events directly
via reflection and delegates to a simple public method on your
ViewModel. My biggest beef with that before was the verbosity of the
XAML when we didn't have lazy initialization for read-only attached
collections. With the lazy initialization, we get to the "nearly
ideal" design I was talking about. However, the XAML is still messier
than what we would have if XAML supported event handlers outside of
the code behind. Fairly minor, I suppose... though there's still the
reflection/security issue with us implementing these solutions. To
really put this to bed, Microsoft has to provide a solution for us.

BTW, I've not looked at the code yet, but the article is top notch! Way to go.

Jeremiah Morrill

unread,
Dec 4, 2008, 5:39:37 PM12/4/08
to wpf-di...@googlegroups.com
You don't know how handy this would be in Silverlight.  Most commanding code I've seen in SL, is an attached behavior, supplying the command name and command property.  The behavior, at run time, looks at what type of control it is and subscribes to "Click" if its a button and "SomeEvent" if its SomeControl.  It would be even more flexible if this idea was extended to take an event for the command in the xaml.

I'll take a look at yer code and see if I can port it to SL.

-Jer

Marlon Grech

unread,
Dec 4, 2008, 5:40:43 PM12/4/08
to wpf-di...@googlegroups.com
mmm... I agree... CanExecute is a bit of "too much" for some scenarios....

I'll keep this in mind and add a cut down version of ICommand so that you can hook an event to a method in the ViewModel... Dude I love talking to you!!! You're the man!

So now you really managed to screw my weekend big time... now only I have to add a collection of CommandBindings but I need to have a cut down version of ICommand.... anything else you want to add ... LOL you're the man dude!


Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/



Jeremiah Morrill

unread,
Dec 4, 2008, 5:53:34 PM12/4/08
to wpf-di...@googlegroups.com
I noticed you said it uses reflection and won't work in XBAP...but I *think* reflection is fine in partial trust just as long as you only reflect public members.  I could be remembering wrong.

-Jer

Mike Brown

unread,
Dec 4, 2008, 6:00:32 PM12/4/08
to wpf-di...@googlegroups.com
Bill,
I wrote an attached behavior and MarkupExtension that does just what you wanted the last time you brought this up. You never commented on the solution I presented though :P

Josh Wagoner

unread,
Dec 4, 2008, 6:27:36 PM12/4/08
to wpf-di...@googlegroups.com
Marlon,

This is great stuff, I presented something very similar at TechEd Barcalona last year (2007) in a pretty unanimously disliked presentation (almost all feedback was negative :-(, maybe the content was not appropriate for the audience).  I also presented it at WPF bootcamp Karsten put on a while back.  I think the video is online somewhere.  Anyhow, you can take download it from here.  It's the source code for the second presentation listed and it's in the AttachedProperties folder (It's the RoutedEventCommandSource class).  Mine only works with routed events, but it's very close.  (There are several bugs in this source that have sense been fixed, if anyone is interested I could try to push up the latest version somewhere).

When I showed it to all the guys on my team they also thought it was limiting that for each element you could only wire up one routed event to one command, but in practice I've found it meets most scenarios.  It would be nice to have a version that could take a collection of routed events and commands.  I've created an ICommand implementation that allows for grouping commands in order to get multiple commands to a single event though.  I've used an approach like this on every project I've worked on over the last year and find it almost required for building the kinds of UIs our designers come up with while sticking to using MVVM.  I often attach view model commands to lots of events other than click, GotFocus, LostFocus, different preview events, etc.  You'll find tons of uses for your new code. :-)

Nicely done,

Josh

Marlon Grech

unread,
Dec 4, 2008, 5:43:23 PM12/4/08
to wpf-di...@googlegroups.com
Cool Jer!!!!

If you need any help or do not understand something in the code (why I did it like that or something) I am more than happy to help! If you guys want my msn just send me an email... I would be more than happy to chat!

P.S For my msn send me an email and I will send it to you... This is a public thread so... you know... I don't want all the hot chicks reading this thread to add me on MSN :P


Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/



Marlon Grech

unread,
Dec 5, 2008, 3:39:06 AM12/5/08
to wpf-di...@googlegroups.com
Thanks Josh.... I will have a look at your code and see how you did yours.... cool stuff...


Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/



Marlon Grech

unread,
Dec 4, 2008, 6:05:11 PM12/4/08
to wpf-di...@googlegroups.com
mmm... not sure... can anyone confirm this..... not sure... It would be wicked if it works as well


Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/



Bill Kempf

unread,
Dec 5, 2008, 8:43:48 AM12/5/08
to wpf-di...@googlegroups.com

Bill Kempf

unread,
Dec 5, 2008, 9:04:00 AM12/5/08
to wpf-di...@googlegroups.com
Hmm... guess I didn't look at it close enough last time. Looks
promising. My only issue currently is that it's not all that reusable
(you need a extension for every event type, and possibly other magic,
such as the CommandBindingAdapter, for every source type). However,
it's an effective pattern that can be applied to specific scenarios.
I'm not sure if this is better than an ActionMessage approach, though
it certainly has the syntax I talked about.

Thanks for pointing this out again, Mike.

Marlon Grech

unread,
Dec 5, 2008, 10:16:20 AM12/5/08
to wpf-di...@googlegroups.com
hey guys,

I am working on the features that Bill suggested.... Right now I already have a version with Actions. An Action would be a light weight Command with no CanExecute. Basically it would be just a Delegate of type Action<T>... Something like this

 <Border Background="DarkSalmon" Width="350" Margin="0,0,10,0" Height="35" CornerRadius="2"
                        local:CommandBehavior.Event="MouseDown" 
                        local:CommandBehavior.Action="{Binding DoSomething}"
                        local:CommandBehavior.CommandParameter="from the DarkSalmon Border :P"/>

and the model would expose a property like this
public Action<object> DoSomething { get; private set; }

I am also working on the Collection of Behaviors... When ready it should look like this

<Border Background="Yellow" Width="350" Margin="0,0,10,0" Height="35" CornerRadius="2">
        <local:CommandBehaviorCollection.Behaviors>
               <local:BehaviorBindingCollectionExtension>
                    <local:BehaviorBinding Event="MouseLeftButtonDown" Action="{Binding DoSomething}" CommandParameter="An Action on MouseLeftButtonDown"/>
                    <local:BehaviorBinding Event="MouseRightButtonDown" Command="{Binding SomeCommand}" CommandParameter="A Command on MouseRightButtonDown"/>
                </local:BehaviorBindingCollectionExtension>
         </local:CommandBehaviorCollection.Behaviors>
</Border/>

I just need to work around some issues I found with the DataContext not being shared in the BehaviorBinding... Mr. Freezable help :P

Will send you guys an early build to try out before I push this on my blog.

I really love how this is coming up... The code is clean no rocket science. I am using the strategy pattern to decide how the binding should be done (if it is a Command or an Action)... Can't wait to share it with you guys and get you feedback, but I must finish the collection thingy first :)

Bill thanks! your suggestions where great :)


Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/



John Gossman

unread,
Dec 5, 2008, 1:28:03 PM12/5/08
to wpf-di...@googlegroups.com
Might as well send everybody what I told Marlon privately the other day:

Yeah.  Looks nice.  You should know the Prism team is doing something very similar for their Silverlight port...they need it because of the lack of even ICommandSource, but they're making it more general. 

My gut is that it doesn't make sense to disable the attached element when the command cannot execute *unless* it is the primary command (ICommandSource).  But in that case you don't need to use the CommandBehavior.  This also of course means you don't need to use CanExecute or CanExecuteChanged, which gets back to my original idea:  just point the event at a method.

Josh Wagoner

unread,
Dec 5, 2008, 1:37:46 PM12/5/08
to wpf-di...@googlegroups.com
John,

Could you expand on "just point the event at a method"?  I'm not sure I follow what you are suggesting there. (Sorry if I missed an earlier mail).

Josh

Marlon Grech

unread,
Dec 5, 2008, 2:00:51 PM12/5/08
to wpf-di...@googlegroups.com
I think what John is referring there is to forget the Command and just point an event to an event handler in the ViewModel. I implemented this in the v2 where the user can specify an Action.


Regards
Marlon
WPF Blog - http://marlongrech.wordpress.com/



Reply all
Reply to author
Forward
0 new messages