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-us...). 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 :).
On Thu, Dec 4, 2008 at 10:44 PM, Bill Kempf <weke...@gmail.com> wrote:
> 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-us... > ). > 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 :).
> On Thu, Dec 4, 2008 at 4:30 PM, Marlon Grech <marlongr...@gmail.com> > wrote: > > 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.
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.
On Thu, Dec 4, 2008 at 9:49 PM, Marlon Grech <marlongr...@gmail.com> wrote: > 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
> On Thu, Dec 4, 2008 at 10:44 PM, Bill Kempf <weke...@gmail.com> wrote:
>> 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-us... >> ). >> 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 :).
>> On Thu, Dec 4, 2008 at 4:30 PM, Marlon Grech <marlongr...@gmail.com> >> wrote: >> > 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.
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:
On Thu, Dec 4, 2008 at 4:49 PM, Marlon Grech <marlongr...@gmail.com> wrote: > 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
> On Thu, Dec 4, 2008 at 10:44 PM, Bill Kempf <weke...@gmail.com> wrote:
>> 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-us...). >> 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 :).
>> On Thu, Dec 4, 2008 at 4:30 PM, Marlon Grech <marlongr...@gmail.com> >> wrote: >> > 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.
On Thu, Dec 4, 2008 at 10:59 PM, Bill Kempf <weke...@gmail.com> wrote:
> 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:
> 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! :)
> On Thu, Dec 4, 2008 at 4:49 PM, Marlon Grech <marlongr...@gmail.com> > wrote: > > 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
> > On Thu, Dec 4, 2008 at 10:44 PM, Bill Kempf <weke...@gmail.com> wrote:
> >> 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-us... > ). > >> 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 :).
> >> On Thu, Dec 4, 2008 at 4:30 PM, Marlon Grech <marlongr...@gmail.com> > >> wrote: > >> > 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.
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.
On Thu, Dec 4, 2008 at 5:07 PM, Marlon Grech <marlongr...@gmail.com> wrote: > Well I see command fitting in quite well for this... This is one reason why > I created the ACB... no more codebehind....
> On Thu, Dec 4, 2008 at 10:59 PM, Bill Kempf <weke...@gmail.com> wrote:
>> 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:
>> 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! :)
>> On Thu, Dec 4, 2008 at 4:49 PM, Marlon Grech <marlongr...@gmail.com> >> wrote: >> > 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
>> > On Thu, Dec 4, 2008 at 10:44 PM, Bill Kempf <weke...@gmail.com> wrote:
>> >> 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-us...). >> >> 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 :).
>> >> On Thu, Dec 4, 2008 at 4:30 PM, Marlon Grech <marlongr...@gmail.com> >> >> wrote: >> >> > 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.
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.
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!
On Thu, Dec 4, 2008 at 11:19 PM, Bill Kempf <weke...@gmail.com> wrote:
> 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.
> On Thu, Dec 4, 2008 at 5:07 PM, Marlon Grech <marlongr...@gmail.com> > wrote: > > Well I see command fitting in quite well for this... This is one reason > why > > I created the ACB... no more codebehind....
> > On Thu, Dec 4, 2008 at 10:59 PM, Bill Kempf <weke...@gmail.com> wrote:
> >> 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:
> >> 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! :)
> >> On Thu, Dec 4, 2008 at 4:49 PM, Marlon Grech <marlongr...@gmail.com> > >> wrote: > >> > 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
> >> > On Thu, Dec 4, 2008 at 10:44 PM, Bill Kempf <weke...@gmail.com> > wrote:
> >> >> 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-us... > ). > >> >> 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 :).
> >> >> On Thu, Dec 4, 2008 at 4:30 PM, Marlon Grech <marlongr...@gmail.com> > >> >> wrote: > >> >> > 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.
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
On Thu, Dec 4, 2008 at 2:39 PM, Jeremiah Morrill <jeremiah.morr...@gmail.com
> wrote: > 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
> On Thu, Dec 4, 2008 at 1:30 PM, Marlon Grech <marlongr...@gmail.com>wrote:
>> 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.
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
> On Thu, Dec 4, 2008 at 10:59 PM, Bill Kempf <weke...@gmail.com> wrote:
>> 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:
>> 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! :)
>> On Thu, Dec 4, 2008 at 4:49 PM, Marlon Grech <marlongr...@gmail.com> >> wrote: >> > 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
>> > On Thu, Dec 4, 2008 at 10:44 PM, Bill Kempf <weke...@gmail.com> wrote:
>> >> 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-us... >> ). >> >> 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 :).
>> >> On Thu, Dec 4, 2008 at 4:30 PM, Marlon Grech <marlongr...@gmail.com> >> >> wrote: >> >> > 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.
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 <http://blendables.com/labs/labs_techEd07.aspx>. 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. :-)
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
jeremiah.morr...@gmail.com> wrote: > 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
> On Thu, Dec 4, 2008 at 1:30 PM, Marlon Grech <marlongr...@gmail.com>wrote:
>> 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.
> 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 <http://blendables.com/labs/labs_techEd07.aspx>. 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
> On Thu, Dec 4, 2008 at 1:30 PM, Marlon Grech <marlongr...@gmail.com>wrote:
>> 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.
jeremiah.morr...@gmail.com> wrote: > 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
> On Thu, Dec 4, 2008 at 2:39 PM, Jeremiah Morrill < > jeremiah.morr...@gmail.com> wrote:
>> 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
>> On Thu, Dec 4, 2008 at 1:30 PM, Marlon Grech <marlongr...@gmail.com>wrote:
>>> 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.
On Thu, Dec 4, 2008 at 6:05 PM, Marlon Grech <marlongr...@gmail.com> wrote: > mmm... not sure... can anyone confirm this..... not sure... It would be > wicked if it works as well
> On Thu, Dec 4, 2008 at 11:53 PM, Jeremiah Morrill > <jeremiah.morr...@gmail.com> wrote:
>> 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
>> On Thu, Dec 4, 2008 at 2:39 PM, Jeremiah Morrill >> <jeremiah.morr...@gmail.com> wrote:
>>> 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
>>> On Thu, Dec 4, 2008 at 1:30 PM, Marlon Grech <marlongr...@gmail.com> >>> wrote:
>>>> 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.
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.
On Thu, Dec 4, 2008 at 6:00 PM, Mike Brown <mbrow...@gmail.com> wrote:
> 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
>> On Thu, Dec 4, 2008 at 10:59 PM, Bill Kempf <weke...@gmail.com> wrote:
>>> 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:
>>> 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! :)
>>> On Thu, Dec 4, 2008 at 4:49 PM, Marlon Grech <marlongr...@gmail.com>
>>> wrote:
>>> > 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
>>> > On Thu, Dec 4, 2008 at 10:44 PM, Bill Kempf <weke...@gmail.com> wrote:
>>> >> 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-us...).
>>> >> 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 :).
>>> >> On Thu, Dec 4, 2008 at 4:30 PM, Marlon Grech <marlongr...@gmail.com>
>>> >> wrote:
>>> >> > 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.
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
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 :)
On Fri, Dec 5, 2008 at 3:04 PM, Bill Kempf <weke...@gmail.com> wrote:
> 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.
> On Thu, Dec 4, 2008 at 6:00 PM, Mike Brown <mbrow...@gmail.com> wrote: > > 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
> >> On Thu, Dec 4, 2008 at 10:59 PM, Bill Kempf <weke...@gmail.com> wrote:
> >>> 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:
> >>> 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! :)
> >>> On Thu, Dec 4, 2008 at 4:49 PM, Marlon Grech <marlongr...@gmail.com> > >>> wrote: > >>> > 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
> >>> > On Thu, Dec 4, 2008 at 10:44 PM, Bill Kempf <weke...@gmail.com> > wrote:
> >>> >> 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-us... > ). > >>> >> 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 :).
> >>> >> On Thu, Dec 4, 2008 at 4:30 PM, Marlon Grech <marlongr...@gmail.com
> >>> >> wrote: > >>> >> > 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.
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.
On Fri, Dec 5, 2008 at 7:16 AM, Marlon Grech <marlongr...@gmail.com> wrote: > 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
> 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 :)
> On Fri, Dec 5, 2008 at 3:04 PM, Bill Kempf <weke...@gmail.com> wrote:
>> 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.
>> On Thu, Dec 4, 2008 at 6:00 PM, Mike Brown <mbrow...@gmail.com> wrote: >> > 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
>> >> On Thu, Dec 4, 2008 at 10:59 PM, Bill Kempf <weke...@gmail.com> wrote:
>> >>> 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:
>> >>> 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! :)
>> >>> On Thu, Dec 4, 2008 at 4:49 PM, Marlon Grech <marlongr...@gmail.com> >> >>> wrote: >> >>> > 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
>> >>> > On Thu, Dec 4, 2008 at 10:44 PM, Bill Kempf <weke...@gmail.com> >> wrote:
>> >>> >> 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-us... >> ). >> >>> >> 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 :).
>> >>> >> On Thu, Dec 4, 2008 at 4:30 PM, Marlon Grech < >> marlongr...@gmail.com> >> >>> >> wrote: >> >>> >> > 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.
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).
On Fri, Dec 5, 2008 at 10:28 AM, John Gossman <gossmans...@gmail.com> wrote:
> 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.
> On Fri, Dec 5, 2008 at 7:16 AM, Marlon Grech <marlongr...@gmail.com>wrote:
>> 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
>> 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 :)
>> On Fri, Dec 5, 2008 at 3:04 PM, Bill Kempf <weke...@gmail.com> wrote:
>>> 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.
>>> On Thu, Dec 4, 2008 at 6:00 PM, Mike Brown <mbrow...@gmail.com> wrote:
>>> > 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
>>> >> On Thu, Dec 4, 2008 at 10:59 PM, Bill Kempf <weke...@gmail.com>
>>> wrote:
>>> >>> 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:
>>> >>> 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! :)
>>> >>> On Thu, Dec 4, 2008 at 4:49 PM, Marlon Grech <marlongr...@gmail.com>
>>> >>> wrote:
>>> >>> > 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
>>> >>> > On Thu, Dec 4, 2008 at 10:44 PM, Bill Kempf <weke...@gmail.com>
>>> wrote:
>>> >>> >> 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-us... >>> ).
>>> >>> >> 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 :).
>>> >>> >> On Thu, Dec 4, 2008 at 4:30 PM, Marlon Grech <
>>> marlongr...@gmail.com>
>>> >>> >> wrote:
>>> >>> >> > 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.
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.
On Fri, Dec 5, 2008 at 7:37 PM, Josh Wagoner <wagoner.j...@gmail.com> wrote: > 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
> On Fri, Dec 5, 2008 at 10:28 AM, John Gossman <gossmans...@gmail.com>wrote:
>> 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.
>> On Fri, Dec 5, 2008 at 7:16 AM, Marlon Grech <marlongr...@gmail.com>wrote:
>>> 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
>>> 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 :)
>>> On Fri, Dec 5, 2008 at 3:04 PM, Bill Kempf <weke...@gmail.com> wrote:
>>>> 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.
>>>> On Thu, Dec 4, 2008 at 6:00 PM, Mike Brown <mbrow...@gmail.com> wrote: >>>> > 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
>>>> >> On Thu, Dec 4, 2008 at 10:59 PM, Bill Kempf <weke...@gmail.com> >>>> wrote:
>>>> >>> 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:
>>>> >>> 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! :)
>>>> >>> On Thu, Dec 4, 2008 at 4:49 PM, Marlon Grech <marlongr...@gmail.com
>>>> >>> wrote: >>>> >>> > 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
>>>> >>> > On Thu, Dec 4, 2008 at 10:44 PM, Bill Kempf <weke...@gmail.com> >>>> wrote:
>>>> >>> >> 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-us... >>>> ). >>>> >>> >> 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 :).
>>>> >>> >> On Thu, Dec 4, 2008 at 4:30 PM, Marlon Grech < >>>> marlongr...@gmail.com> >>>> >>> >> wrote: >>>> >>> >> > 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.
|
