As pointed out by a commenter on the previous blog entry, the KryptonCommand would be more useful if it also worked against the KryptonContextMenu. So that is exactly what I have now added. Here you see a KryptonDropButton that shows a simple context menu when pressed…

Once I assign a KryptonCommand instance to each of the compatible menu items we get the following display instead…

As you can see, the menu item, menu check box, menu check button and menu link label all update to account for the settings inside the attached command. Once I press the check button to toggle the checked state it automatically updates all the appropriate menu items…

This brings me to another change I made. Until now the only change to a menu item that would be reflected in an already displaying context menu was CheckState. I have now expanded on this so that Text, ExtraText, Image and Enabled properties also immediately updated in a showing context menu.

There is one caveat though. Although the image and text will be updated the size of the item will not change. So if you assign a larger text string than before the context menu will not auto expand so it can be all be shown. It just uses the existing sizing. Not perfect but certainly an improvement on the previous functionality.

The KryptonCommand is not an analog for an existing WinForms component. With the proliferation of controls for showing and initiating actions it makes sense to simplify this common task. This is where the KryptonCommand comes into play.

Instead of setting the same state into multiple controls you just assign the state to a single instance of the KryptonCommand and then assign the command object to the controls. Now when you update the command it automatically updates all the controls for you. Here are a set of Krypton Toolkit controls placed on a KryptonPanel…

I now create a KryptonCommand and set its image to be that of an angel and the text properties to something simple. Assigning the command instance to each controls KryptonCommand property updates them to the following…

Now any change to the command object is reflected in all the controls immediately. So if I change the commands Checked property to be True you get the following…

Obviously not all the controls have the ability to represent a checked state, so only the ones where it is relevant are updated. For example the label controls obviously cannot be checked and so ignore this setting.

Notice at the bottom that you can assign the command to individual ButtonSpec instances. This applies to button specs on the Ribbon, Navigator and all relevant Toolkit controls. This is a two way process, so if you click a button that understands the checked property then it alters the command to reflect this checked state change.

Relevant KryptonRibbon elements have also been updated to the use the command. Here we have a ribbon group with some standard elements being displayed…

And once the command is assigned…

With the KryptonCommand.Checked = True…

If I now clicked on the first button element so that it was no longer checked then the other checked items would automatically become unchecked as well. This is because any change is reflected back to the command instance and all other controls attached to the command are therefore updated as well.  Although not shown above, the quick access toolbar buttons also take the command object.

The KryptonCommand issues a couple of events so that you can hook into a change in any of the properties and also be notified whenever the command needs to be executed. This allows the real power of the components to be unleashed.

A typical scenario might be handling the print action within your application. You create a command that has the appropriate text and images for indicating this print option. Then you can assign this command to a ribbon quick access toolbar button, a ribbon group button, a standalone button inside the client area and even to a button spec on a header. Whenever any of these elements is clicked you get the Execute event and can perform the actual printing action. If you decide to disable printing then just set the command Enabled property to False and all are updated immediately.

Now you can easily update and retain state without having to worry about updating every relevant control in your application. Once your application starts to grow this can become a real headache unless you deliberately manage this issue. Well now you can handle it with ease!

Regular readers of this blog will not be surprised to see the addition of a checked list box. I tend to add controls to related groups so once the KryptonListBox was added the checked variant was a certainty. Here you can see the control in all its glory…

If you decide to add KryptonListItem instances instead of standard string objects then you can provide a richer level of content very easily…

You can set the CheckOnClick property so that the first click of an item causes its checked state to be toggled. Without this you have to first of all select the item and then afterwards click a second time for the checked state to be altered.

Are there any other list box variations that would make sense? I did think of adding one that shows radio buttons in place of the check box and enforces the idea of only a single item having the radio button checked at a time. But in practice I am not sure it would actually be useful.

I like to think one of the strengths of the Krypton Toolkit is the way it incorporates feedback from users. For example, today a developer requested a simple addition to the ButtonSpec to make their life a little easier. In response to his thread I have added Tag and Owner properties.

The Tag property allows you to associate any arbitrary object you like to the ButtonSpec instance. Owner is a reference to the component/control that owns that particular ButtonSpec. This allows you to hook multiple ButtonSpec.Click events to the same single event handler, examining the Owner/Tag to decide how to act.

This is easier than having to maintain some extra dictionary lookup to find the control that owns the instance or having to implement a different handler per button spec instance. A simple and quick change but one that makes life just that bit easier for developers.

I’ve been missing the Larkware News web feed since it stopped being produced at the end of 2007. It provided a useful round up of interesting links relating mostly to .NET developers. It was a great time saver. But there seems to be a new kid on the block producing something very similar called The Morning Brew.

I hope Chris can manage to keep up the current level of detail. Maybe he should try offering advertising spots to help cover the bandwidth and server costs.