One of the common scenarios for using the KryptonHeaderGroup is to provide expanding/collapsing groups. This has now been made a whole lot simpler to implement.

Arrow ButtonSpecs

When implementing an expanding/collapsing group your first task is to add a ButtonSpec so that you can show an appropriate image on the header. At the moment you have to create this image yourself and then assign it to the Image property of the ButtonSpec.

This is such a common requirement that I have added four builtin button types so you only need to select the type required. Here is a header group with each of the ArrowLeft, ArrowUp, ArrowRight, and ArrowDown types showing.

Just like the existing Context and Close button types the default values for the new arrow buttons are exposed via the KryptonPalette, so you can ensure the images are customized appropriately to match the rest of your custom palette design.

KryptonHeaderGroup properties

There are three new properties for the KryptonHeaderGroup that provide the expanding/collapsing functionality for you. These are called AutoCollapseArrow, Collapsed and CollapsedTarget.

The Collapsed property is a simple boolean property that specifies if the control is in the collapsed or expanded mode of operation. By default the control is created in the expanded state.

When defined as collapsed the value of the CollapseTarget is used to determine which of the headers should be shown. If you choose Collapse to Primary Header then the primary header will be visible and the secondary header hidden. When collapsed the client area is always hidden from view.

Our third property is AutoCollapseArrow and is used to automate updates to the Collapsed property. When the user clicks an arrow button spec the control will automatically toggle the collapsed state and also invert the direction of the showing arrow.

For example, if the header has a button spec of type ArrowUp and the AutoCollapseArrow property is defined as True then the following happens when the user presses the button. The Collapsed state is inverted from True to False or vica versa. Then the button spec is changed to point in the opposite direction by being updated to ArrowDown.

So by leaving all the three new properties as the default values you can add basic collapse/expanding functionality by adding a single button spec which points in the appropriate direction.

I will be updating the examples and the tutorials in the documentation to use the new properties instead of the existing hand coded mechanism.

All the palette styles have been renamed to more meaningful monikers and extra custom styles added to allow easier development of custom themes.

Renamed Styles

As requested by several heavy users of the library as well as members of the forum, the names of palette styles have been revamped. This should make it much easier to remember which style is appropriate for use in any given situation. For example the Button1, Button2 and Button3 styles are now called ButtonStandalone, ButtonLowProfile and ButtonButtonSpec.

Custom Styles

Also in response to feedback from users is the addition of some custom styles. These styles are guaranteed to never be used as the default for any of the krypton controls. So you can modify the custom styles for personal use without fear it will corrupt the look of existing krypton controls. Examples of custom names are ButtonCustom1, ButtonCustom2 and LabelCustom1.

Table of new names

Here is a list of all the new names with the corresponding old name if it was present in the old naming scheme.


ButtonStandalone <- Button1
ButtonLowProfile <- Button2
ButtonButtonSpec <- Button3
ButtonCustom1
ButtonCustom2
ButtonCustom3

SeparatorLowProfile <- Separator1
SeparatorHighProfile <- Separator2
SeparatorCustom1


Upgrading Palettes

To support the palette changes the format of the palette xml files has been updated. This change means you cannot load a palette xml file into verison 1.2 of the toolkit that was saved using the existing version 1.1.

Obviously it is not acceptable that users of the toolkit have to create new palette definition files from scratch, not just this time around but anytime that the palette file format changes. So I have created an upgrade tool that takes in your existing version 1.1 xml file and converts it to the latest format.

As the palette files are just XML it was simple enough to create an XSL transformation than can be applied to the file to perform the necessary change in structure. The upgrade tool can be found and started from the Krypton Explorer application.

Krypton Explorer

When you install version 1.2 of the toolkit you will get a shortcut on your deskop that starts Krypton Explorer. This is the new name for what at the moment is currently called the Krypton Launcher.

The change in name reflects that it does more than just launch a few example applications. It provides links to resources, documentation and sample source code. It has been revampled to reflect the increasing number of examples and links that are part of the toolkit.

You know the famous saying, ‘The King is dead, long live the King!’. Well my version would be ‘The Renderer is dead, long live the Renderer!’.

In version 1.1 of the toolkit there are properties on each krypton control for specifying the renderer to be used. At the moment there is only a single renderer and so I doubt anyone has actually needed to use the properties.

You could create your own renderer by implementing the IRenderer interface or a new component or extend the existing renderer by deriving from the RenderStandard class. As not a single developer has contacted me about creating a custom renderer I assume that either no one has needed to do so, the most likely reason, or the process is so simple they just have not needed any help.

As well as having per-control properties there are global properties exposed on the KryptonManager so that you can alter the rendering of all krypton controls in one go. This mirrors exactly the same mechanism used to specify per-control and global palettes.

Although it seemed a go idea at the time I no longer believe this is the best approach. In reality the renderer is going to be closely associated with a palette. The professional palette will want to use the professional renderer, the Office2007 palette will want the Office2007 renderer.

Note: There is currently no Office2007 palette or renderer but I have plans of creating these additions in the future. I expect to add the Office2007 look and feel in version 1.4 of krypton.

So the RenderMode and Renderer properties have been removed from the individual krypton control and the GlobalRenderer and GlobalRenderMode have been removed from the KryptonManager. Now the actual palette instance provides the renderer that should be used for drawing.

This is much more logical because as you select a different palette you will automatically also switch to using the appropriate renderer for that palette.

If you create your own custom palette by using the KryptonPalette component then you have the chance to use the new properties that it exposes. These allow you to define the renderer you want used for the custom palette.

Althought it sounds like a lot of changes, in reality it should not impact your existing krypton based applications, a simple recompile is all that is required.

To finish this current cycle of development I have added some design time support via smart tags. This makes it a little easier to find the properties relevant to the current mode.

Here is the smart tag showing when using the simplist navigator mode of Panel.

When you switch to another mode the smart tag will update automatically to show the properties relevant to that mode. Here we have used the smart tag to change to the HeaderGroup mode.

I am now switching back to working on the next revison of the Krypton Toolkit. This is because I need to add a few features so that the navigator can use those features to implement the next few modes.

This is what happened recently when I needed the ButtonSpec capabilities in the navigator. That lead to the creation of version 1.1 of the toolkit. This time I need something called the KryptonDivider. This is really just a border that can be placed between control instances. I need this ability in order to create the Outlook style control that I want to add as the next mode.

Today I’ve started work on version 1.2 of the Krypton Toolkit. I have a fairly long wish list of requirements from users of the library so I cannot promise to add everything.

First up is some work on the KryptonPalette. I am in the process of renaming all the existing styles and adding some custom styles that can be used for any purpose the developer needs. The forum topics on these two changes indicated that you were keen to see these changes happen. Once that task is done I will post a list of all the new style names so you have a chance to object if you think they are not clear enough.

In the mean time this is your chance to make suggestions and indicate changes you would like to see in the palette area. By the middle of next week I will have moved onto another area and will not be revisiting palettes until the next release cycle.