It seems that the CheckableCommands from the Ribbon Library are not in the Bar Library

Bars for WPF Forum

Posted 22 days ago by Matthew Moloney
Version: 24.1.1
Avatar

First, a quick sainty check to see if I have missed something and there is indeed an analog for CheckableCommands from the Ribbon Library in the Bars Library.

Second, I would just like to voice that really liked this functionality. I'm guessing the intent of the removal is to push this functionality into a ViewModel but I don't use MVVM so not having this functionality is rather cumberson. Logically it makes sense that controls can use more feedback than just the boolean CanExecute and I prefer to lean on the visual tree rather than use explicit bindings. I know you had to smuggle it in as a command parameter which is a bit of a hack and ideally it would have been built into WPF. I'll try subclassing BarToggleButton to see if I can add this functionality back in but am not overly optimistic.

Comments (2)

Answer - Posted 22 days ago by Actipro Software Support - Cleveland, OH, USA
Avatar

Hi Matthew,

You are correct, Bars doesn't implement anything like the CheckableCommand functionality that was in the older Ribbon product.  The CheckableCommand functionality was indeed handy, however was implemented in a non-standard way that didn't work well with MVVM.  As you said, using the command parameter (and really even commands in general) for tracking things like checked state, did have the feel of a hack.

A main goal of Bars was to completely support MVVM from the ground up.  The newer ribbon control implementation in Bars follows MVVM best practices and uses all familiar techniques that anyone using WPF or MVVM should be well versed in.  It's really a much better overall setup.


Actipro Software Support

Posted 21 days ago by Matthew Moloney
Avatar

I was able to subclass the BarToggleButton and override the CommandParameter property to provide the callback to set IsChecked and it seems to work perfectly fine and I’m happy with the result. While these fixes are ‘hacks’ I do think it was one of many oversights in WPF that would have eventually been properly fixed had development of WPF continued.

I understand that I’m in the minority of UI developers that do not like MVVM, I see it as one of many design patterns and generally worse than a domain specific design pattern. MVVM is usually a better separation of concerns than what would have been built by inexperienced developers so it serves a purpose as a lowest common denominator. I also understand the commercial expedience that necessitates its support by component suppliers. I think both the WPF team and the Patterns and Practices group at Microsoft that evangelized MVVM did make a number of mistakes as artifacts of history that we are still suffering from. Thorough first class support for generics and lambdas being some of the more obvious ones – and understandably given the necessary language features were not available at the time. The LINQ performance issues from upcasting everything to IEnumerable and the compositional difficulty of ReactiveX did not help either. My general point is that I worry about people seeing MVVM as a panacea and more specifically I worry about the removal of features on the basis that they don’t fit neatly within the MVVM paradigm.

The latest build of this product (v24.1.2) was released 6 days ago, which was after the last post in this thread.

Add Comment

Please log in to a validated account to post comments.