DarksideCookie

The other day, a reader called MAX pointed out to me that the CommandManager has a major flaw. It stores all commands in a static list. This keeps the garbage collection from working as it should, as the commands are always referenced. The commands in turn reference the controls that use them. So the CommandManager actually keeps any control that uses commanding from being GC:ed. So, because of this, I have changed the CommandManager code once more. This time however, I have not just added some information here and posted the new code for download. Instead, since the CommandManager seems to never die, I have put it on Codeplex making it available at http://agcommandmanager.codeplex.com.

The CommandManager never dies? …have I forgotten about Silverlight 4? No, not at all. Silverlight 4 has a bit of commanding built into it. It supports binding ICommands to Command properties on some controls, such as Buttons. This is great and will definitely limit the need for the CommandManager. The CommandManager has one thing that Silverlight 4 does not have. It supports binding ICommands to more or less any event. So if anyone needs this kind of flexibility, the CommandManager is the way to go…

[UPDATE]
The code for the CommandManager has been rewritten due to some memory management issues. And together with that change, I have decided to put it on Codeplex. My blog posts about it are still more or less valid, but I suggest also taking a look at the code at http://agcommandmanager.codeplex.com/.
[/UPDATE]

Once again I return to the CommandManager that I have blogged about before. And I know it is getting boring and that I some day must leave that behind me and go forward. However, after having had a look at Prism/CAG/CAL and seen how Microsoft solves the commanding infrastructure, I have decided that the CommandManager still fills a purpose.

I also had a plan to retire the CommandManager completely and implement something similar using Behaviors. However, Behavior<T> or what ever it is called, inherits directly from DependencyObject instead of from FrameworkElement. This made it really hard to use in this situation, since it doesn’t support data binding. So I had to scrap that idea for now. It seems as if Microsoft uses this idea in Prism, but introduces an extra static object to get it to work… At least in the Prism implementation I have been looking at.

So why do I return to the CommandManager again? Just to argue that it is great and boost my ego? No…apparently, my previous implementation had a flaw. I might have a lot more, but I discovered one that caused problems. So I have rectified that…

More...

A little while ago I got a question on my blog about how to attach multiple commands to a control. That was something that is so obvious and so obviously not supported in the first version of the command manager. So I quickly wrote a message back saying that I would build that and it would be up on the blog soon. Well…I ran into some trouble…so it took a little longer than expected. And the solution might not be the best, but it works. So here it is…the CommandManager 2.0.

More...

After having worked a bit with the Mode View ViewModel pattern in Silverlight, I've sort fallen into a trance chanting "MVVM, MVVM, MVVM". It gives the developer such a good platform to work with. The MVVM pattern is a modified version of the MVC and MVP patterns. By now, you are probablyabout to closer your browser due to the pattern rant I'm on. Well, don't. This isn't about MVVM really, only a little. The MVVM pattern was "created" by John Gossman at Microsoft, specifically to target WPF. This also means that it works great in Silverlight. But Silverlight is smaller, and missing some features... The CommandManager is one of them. This post shows a way to handle this shortcoming.

More...