To select a KryptonGroup instance at design time requires you to click on the single pixel border of the control. This behavior is just plain irratating; so a new selection glyph has been added.

Here is a KryptonGroup instance at design time.

To simplify selection I now show a selection glyph in the bottom right corner of the control when the mouse is hovering inside the client area.

Clicking on the glyph causes the whole KryptonGroup to become selected instead of selecting the contained panel. Here it what you see when you click the glyph.

If you do actually want to select the internal panel then you just click in the panel area but not on the glyph itself. Like this.

This is such a simple and effective technique I decided to extend it to all the krypton controls that have contained panels. Here are the KryptonHeaderGroup, KryptonSplitContainer and KryptonNavigator all showing the new glyph which when pressed selects the whole control.

Using the glyph honors all the selection semantics. So if you are keeping the SHIFT key down to create a multiple selection then pressing the glyph will add the control to the selection.

You would have thought adding scrollbars to the new stacking modes was a simple couple of hours job. Well it turned into a four day marathon but we got there in the end.

Scrollbars are needed when you have too many pages stacked to fit into the available space in the navigator. For example, you can see in the picture below that there are several stack items that are off the end of the control.

The vertical scrollbar is shown so you can navigate to and select the extra items off the end of the client area. It would also use a horizontal scrollbar if the selected page is wider than the available space.

Looks simple enough to implement but required much refactoring of code to handle the extra complications it generated. Such as correctly handling internationalized by swapping the vertical scrollbar side when working in right-to-left-layout mode. Not to mention getting the sizing and positioning correct with respect to minimum/maximum/preferred settings for the selected krypton page. Plus getting child controls on the selected page to honor anchoring as expected.

Still, we got there in the end and now I am going to lay down with a cold towel around my head for a while.

In response to a request on the forum I have expanded the options available for importing and exporting KyptonPalette definitions.

In the current release you have only one option for saving and loading a palette definition. You must save to an xml file. But this makes it difficult to handle a couple of the most common real world requirements.

Database Storage
There are now Export and Import overrides that operate on arrays of bytes. So calling the appropriate version of Export will return i>byte[]. This is easy to then store in a database of your choice.

If you prefer to store it in your database as a string type rather than as raw bytes then you can always call Convert.ToBase64String(…) first. Then use the Convert.FromBase64String(…) to convert it back to an array of bytes for the Import call.

If instead of a database you are using your own persistence mechanism then the option of using the byte array or converted Base64 string allows you to integrate the palette information.

Embedded Palettes
A second likely scenario is that you have a palette definition file you created using the PaletteDesigner and would like to distribute it with your application and have it loaded and used at runtime.

This is where the second set of Export and Import overloads come into play. They both take a Stream instance as the source for loading from or saving into. To import using this overload from an embedded resource just do the following.

- Add your palette xml file to the project.
- Mark the file as an ‘Embedded Resource’.
- Use the following code to load the resource.


Assembly a = Assembly.GetAssembly(typeof(MyForm));
Stream s = a.GetManifestResourceStream("MyForm.Resources.Palette.xml");
kryptonPalette1.Import(s);


I will add a little tutorial to the next release that gives more detailed step by step instructions on embedding a palette definitions. But as you can see it is pretty trivial.

Two new modes have been added to the KryptonNavigator that show the available pages as a set of stacked check buttons.

Stack – CheckButton – Group
This mode presents a single check button per visible page and shows then stacked within a group container. In the example below you can see the client area of the selected page in the middle of the control, below the currently selected check button entry.

Use the StackOrientation property to switch to a horizontal stack instead of the default vertical arrangement.

Use the StackAlignment property to determine where the check buttons are positioned. The first two pictures used the default setting of Center, where the check buttons appear either before or after the selected entry depending on their position in the pages collection.

If you choose an alignment of Far then all the check buttons are placed at the far end of the container and the selected client area always placed at the top, like so.

Using an alignment of Near would reverse this so all the check buttons are at the top and the selected client area is always at the bottom.

Stack – CheckButton – HeaderGroup

This modes combines a header group as the container and places the stack inside the inner area.

You can play around with the header group settings. Here we have the primary header on the left side and the secondary header hidden. The close and context buttons have also been removed from display.

Feedback
There is a design decision I would appreciate feedback on. If there are too many check buttons for the client area then what would you expect to happen with the display?

Would you except a scrollbar to appear so the user can scroll up and down to the check buttons that cannot be seen? Or some other action to occur?