Customising the appearance of the KryptonButton control can be a time consuming task because you need to alter at least four visual appearance states.

If you want to alter the look and feel of all the controls then altering the settings for the KryptonPalette is an arduous and error prone undertaking. Now that the KryptonCheckButton has been added that means at least seven states need defining just for that one control.

Well obviously this needs resolving and today I have managed to get an improved hierarchy implemented.

Now each of the toolkit controls has a new visual state called StateCommon that works alongside the existing control states. All of the other visual states inherit their values from this instance so for common settings you only need to modify one property instead of several.

For example, you decide your KryptonButton should have a rounded border and so you want to define the Rounding value as 2. In the past you would need to set this for each of the StateDisabled, StateNormal, StateTracking and StatePressed states. Not anymore, now you just define it in one place, StateCommon, and the four states will inherit the value. The KryptonPalette has also been altered so that for each control type the StateCommon can be specified.

Another change to the KryptonPalette is the addition of three new properties that are applied across all the different control types. These are StateCommon, StateDisabled and StateOthers that for the first time allow the specification of values that alter all the different types of control.

The disabled state for all the control types inherit from StateDisabled and all the non-disabled states inherit from the StateOthers property. If no value is found here then the top level StateCommon is used.

So now there is quite a deep hierarchy of inheritance used for defining the appearance of all the toolkit controls. This allows fine grained control over the display but also reduces the number of settings that need changing.

Last but not least is a new property on the KryptonManager that controls whether the tool strips are rendered using the toolkit. At the moment any use of the toolkit will mean that the tool strips use a custom renderer provided by the toolkit that draws the menu/tool/status strips using the colors from the current global palette. This is obviously no use if you happen to want to use your own custom renderer. So you can now set the GlobalApplyToolstrips property to false to turn this off.

In the future I might need to add some caching of values at the lowest level to improve performance but so far I have not noticed any bottlenecks.

In response to feedback I have added a new control to the toolkit.

The KryptonCheckButton class derives from the existing KryptonButton and adds a new property called Checked. As you would expect this property is of type boolean.

To support the checked feedback there are three new visual states called StateCheckedNormal, StateCheckedTracking and StateCheckedPressed.

You could place several of these checked buttons in a row and create a radio button style grouping effect. Although you would need to implement the logic yourself this is a simple enough task. You just hook into the Click event for each instance and then set the Checked property for the selected button and remove it from the previously selected one.

Or would it be useful for me to add a little component that takes a list of checked buttons and automatically adds this logic for you?

Since the initial release of the Krypton Toolkit there have been occasional bug reports. Two of these were particularly important. The incorrect drawing when RightToLeft is defined and incorrect handling of child anchor properties.

Child controls using anchoring

Both the KryptonGroup and the KryptonHeaderGroup controls act as containers and so allow child controls to be displayed. This worked fine if the child control had either a Dock setting or just the standard Top | Left anchoring.

But a couple of developers noticed that if you docked against the Right and/or the Bottom then the child control disappeared. In this case the control was not being layed out before the child control was attempting to use the containers size. Hence the wrong size was used and the child control usually positioned off the client area.

This has now been fixed. In this picture you can see a KryptonHeaderGroup with two standard buttons as children. Once button is anchored to the Bottom | Right and the second to all four edges.

Once we stretch the size of the container we can see that it is correctly updating the size and position of both buttons.

Support for RightToLeft

Another major bug was reported by several developers that require support for right to left systems. Instead of drawing in the expected reversed ordering the drawing was positioned incorrectly and so much of the text was not even visible.

Here are KryptonHeader and KryptonHeaderGroup controls showing in the normal left to right setting.

Now when the window setting for RightToLeft is defined as Yes it correctly reverses the drawing.