I was hoping to get the next release of Krypton finished and out the door today but it’s not going to happen. Tomorrow I am off on a 1 week holiday and there is too much to finish by the end of today.

There are only three outstanding tasks to complete.

Add KryptonNavigator documentation.
Fix a couple of important bugs
Update the website

Because I am away tomorrow everything is now on hold until next Monday. So the new release date is going to be the 6th July. This time I am very confident it will be met!

The new KryptonLinkLabel control is derived from the existing KryptonLabel and adds the ability to act as a hyperlink.

KryptonLinkLabel

The control is very simple and alters the appearance of the short text so it becomes a hyperlink that can be clicked in order to generate a LinkClicked event. Here you can see the control in the normal, tracking and pressed states.

Only the short text is turned into a hyperlink, the long text and image operate in exactly the same static way as the standard KryptonLabel control. You can see proof of that here.

Another change from the existing KryptonLabel control is the ability to take the focus. When you click the control it will automatically take the focus, you can see the focus rectangle in the above examples, as well as take part in standard tab ordering behavior. The user can use the Enter key to press the link when using the keyboard interface.

The control is not intended to mimic all the functionality of the standard LinkLabel that comes with windows forms. So you cannot have multiple link areas within the text. It should however have enough functionality to meet the needs of most hyperlink scenarios.

I have set myself a deadline of next Monday (26th June) for releasing version 1.2 of Krypton. To achieve that I have now frozen the base code for all except bug fixes.

I did have plans on adding a progress bar control but I have run out of time and so you will have to wait until release 1.3. This is a shame as many of the survey reports I am getting back from downloaders indicated it was the most sought after request. However, I need to release version 1.2 by the end of business next Monday as I will be on holiday for 1 week starting next Tuesday.

I want to leave on vacation knowing the next revision is out in the wild. Otherwise I will spend the whole vacation feeling like there is unfinished business back home and so not be able to relax as much as I should. This must be a geek thing as I am sure most programmers are the same, you just don’t want to leave things half done. You want that feeling of having reached a checkpoint that provides a natural break in your workflow.

As I still have to create new examples, update the documentation, update the build process and update the website I have to stop coding new features. Starting today I have frozen the code apart from fixing any bugs that I spot.

Now it is time to work on the collaterals to get the release out of the door.

With the introduction of the Collapse property for the KryptonHeaderGroup we have a new example that shows off how to use it in your applications.

I really love this new example because you can create the entire application that is demonstrated below without writing a single line of code. The whole thing is created at design time using drag and drop and setting a few properties. There will be a new tutorial in the documentation that describes this step by step process.

Here is the application with two KryptonHeaderGroup instances docked to the top of the client area and in the collapsed state.

When you press the expand button for the User Details section it will expand to give the following appearance.

Changing the palette at runtime will cause the header groups to resize as required without any extra code from yourself. Here is the appearance when a custom palette is applied.

Docking Style

This example was built by adding KryptonHeaderGroup instances and then setting the Dock property of each one to be Top. For your own application you can choose to dock against any of the edges or even have each group docked against a different edge. The white group at the bottom is a KryptonGroup that is set to fill the remaining area left over.

Splitter Style

The existing toolkit example that shows expanding and collapsing groups has been renamed to Expanding HeaderGroups (SplitterStyle). That example uses KryptonSplitContainer instances and requires a few lines of code be written in order to work as needed. It needs the manual writing of code because the split container does not know that is contains a header group that requires different split container actions depending on its colapsed state.

It does have the advantage of allowing the user to move the splitter at runtime in order to alter the relative sizing of the groups, although having to write some code is a disadvantage The dock style example does not require extra lines of code but does not allow the user to change the relative size of the groups.

Unless you add a child to the KryptonHeaderGroup that uses the Dock=Fill style then you are leaving yourself open to a couple of issues.

The current design of the KryptonHeaderGroup is to act as a control container so you can drag and drop controls from the toolbox onto the header group. Controls you add are supposed to remain in the client area of the control, the white portion when displayed using the default palette. You can see an instance here with a single button added.

In order to try and ensure that all child controls are positoned correctly the control overrides the DisplayRectangle method. This method returns the client rectangle that represents the acceptable location of child controls. This works fine if you change the button to have a Dock=Fill style setting. The framework will correctly size the button to fill the DisplayRectangle area.

But problems occur when not using a docking style. The framework does not enforce positioning to within the display rectangle. So if you change the position of the secondary header to the left you will see the following appearance.

Although the control has correctly changed the DisplayRectangle value the button control is not moved by the framework. So if you are going to change the edges and/or visiblity of the headers at runtime you can end up with a corupt looking interface.

In additon to the positoning problem we have a second issue of clipping. If you move the button control so it is only partially visible then it draws over the top of the group border. You can see the problem below.

So although the DisplayRectangle method is a useful addition to .NET2 it does not do the full job we need.

Today I have changed the implementation so that a child panel is positoned in the DisplayRectangle area and at design time you can only drop controls onto that child panel and not the header group itself.

This solves the positon and clipping issues. The down side is that existing applications need to be changed to reflect this. But I think the small upgrade pain is worth the effort.