In response to a bug reported on the forums I have fixed up the display and operation of the KryptonRibbon when it is disabled.

I never really considered this scenario as I assumed that no one would want to completely disable the ribbon. I assumed a disabled ribbon would make the whole application inoperable and therefore not a very useful capability. However, I have learnt over the years that people will use your software in ways you would never think of, and with a good reason.

So here is the ribbon in normal enabled mode…

And now disabled…

You wait ages for a new control and then two come along at once!

As you can guess the KryptonCheckBox has the same functionality as the standard Windows.Forms version but with the appearance appropriate to the selected palette. It supports the Checked, Unchecked and Indeterminate display states and gives visual feedback to show tracking and pressed actions.

KryptonCheckBox in Office 2007 – Blue

And in Office 2007 – Silver

As with the KryptonRadioButton, when in the System or 2003 palettes it shows the theme specified appearance. Of course, it themes are not available or not enabled for the application then it reverts to the classic windows appearance instead. Here you can see it reflects the theme appearance correctly.

At last, a new control for the Toolkit!

The KryptonRadioButton provides the same functionality as the standard radio button control but with an appearance that is appropriate for the built-in palette. The implementation is really just a combination of a KryptonLabel with the ability to show an image. So here are some new radio buttons in the Office 2007 – Blue palette.

And now in the Office 2007 – Silver palette…

When using the Professional – System or Professional – 2003 palettes the display reverts to showing the theme specific appearance. This ensures the appearance is appropriate for the current display settings.

This is a bug that has been around for a little while. Imagine you have a KryptonLabel inside a TableLayoutPanel and then set the TableLayoutPanel to be have transparent background. What you should see is the background from behind the table panel drawn as the background of the KryptonLabel.

Sadly this was not happening correctly. Most developers would not notice the issue because they have a solid color as the main background but if you have a gradient fill then you can clearly see the drawing problem.

This problem was not unique to the KryptonLabel but in fact present with any Krypton control that needs to draw some of its background as transparent. It is also exhibited not just when inside a TableLayoutPanel but for any control that can have a transparent background color defined, such as a regular Panel.

I won’t bore you with the tricky details of how the code solves the problem, suffice it to say it involves creating regions and adjusting them for the device content to ensure the drawing occurs in the correct location with correct clipping. Not many lines of code but a real pain to get just right in all circumstances.

To show it works here is an example. You can see below at design time a TableLayoutPanel is placed onto the gradient background. In the left cell of the table is a KryptonHeaderGroup that contains a KryptonPanel that itself contains a KryptonButton and KryptonLabel. The group and panel have been customized to have transparent backgrounds. The right cell contains a button and a couple of labels inside a traditional windows Group instance.

At runtime it works as expected with the main background showing through as required.