This is a maintenance release that contains bug fixes only. It includes all the fixes as described over the last few blog posts.

Some of the bugs are critical and so I wanted to get a bug fixed version released as soon as possible so developers could get on with using Krypton. I will not now go back to working on adding new functionality.

Place a KryptonHeaderGroup inside a TabControl page and you will notice that any children inside the header group disappear at runtime.

Using Spy++ I could see that not only was the Button inside the KryptonHeaderGroup not showing but in fact it had never even been created as a control. It was literally just not there at runtime.

Now if you place the header group inside any of the other containers such as a standard Panel, FlowLayout, GroupBox or any of the Krypton containers that it worked fine. It it just the TabControl that exposes this odd problem.

Well I spent the best part of a day trying to work this one out and even got to the point of decompiling the Wndows.Forms Control class using .NET Reflector to see what was going on under the covers. Combining this with copious Console.WriteLine statements eventually gave me the single clue needed to resolve the issue.

It turns out the problem was triggered from the constructor of the KryptonHeaderGroup when adding the panel for the client area. The act of adding this panel to the control collection causes a layout cycle to occur. The layout cycle causes the layout code to measure the size of the header text. Measuring text requires the use of a device context which itself causes the handle for the control to be created. Apparently this is bad, because if we let the handle be created later on in the natural order of events then the problem disappears.

So the solution is to prevent the layout cycle that occurs because of adding the client area panel in the constructor. No wonder I didn’t think of that when the bug was first reported.

If you select a KryptonHeaderGroup or a KryptonNavigator at design time and then perform a copy & paste it fails to copy everything.

If your KryptonHeaderGroup control contains several child controls then the newly pasted copy would have the original controls leaving the source header group with none. So instead of copying it was moving the controls. Obviously this is somewhat undesirable!

The problem occurs because the designer class for the header group overrides the AssociatedComponents property but fails to pass on the results of calling the base class. It is this returned collection of components that need to be copied, so failing to provide the full list meant the child controls are not copied but just moved instead.

The same problem and solution are applicable to the KryptonNavigator as well. Here it is even more obvious because the pages would not be copied across.

I don’t mean that in the literal sense, of course. But I have been taking the advice of Joel Spolsky and Eric Sink, by using Krypton within an internal application I have written.

This is the first post in over a week because I have been knocking up an application to manage customers and serial keys. Rather than try to find and buy an off the self solution I thought it would be easier to just create exactly what I need myself. Like most programmers I prefer the feely of complete control that comes from writing it to do exactly what I need myself.

It can import sales information directly from an SWREG report or connect to directly to Microsoft Outlook and scan for the sale notification emails. As well as updating the sales database it will generate any required outgoing emails.

So if an order for a 4 Navigator licence arrives it will automatically generate and send out the three additional serial keys (the first one is sent directly by SWREG at the time the order is completed). It has all the usual features you would expect in order to make life easier, the ability to search based on order numbers, email addresses etc.

I can leave it running overnight or over a weekend when I am away and know that the additional emails are being generated. This gives me a high degree of automation, I have Outlook and my internal application up and running at startup and know that my database and emails are taking care of themselves.

This is really important as a small ISV, make sure you automate just about anything you can. That way your not spending time on daily manual tasks and instead can concentrate on the important stuff, like adding features!

The only feature missing that I need is the ability to send reminders at the end of the 12 month subscription period, but I can leave that until closer to the anniversary of the first sale!

So why am I explaining this straight forward application that is no use to anyone else? Well I used Krypton to build the user interface in order to ensure that it really does work as expected in a real world scenario.

During the process I found the ‘anchor not working for controls inside KryptonGroup/KryptonHeaderGroup’ bug. It also gives me more of an insight into the pain points in developing a typical client application.

Now back to the real business of fixing the list of bugs reported for the 2.0 release. As some are quite critical it might be worth issuing a new release that just contains the bug fixes but without any new functionality.

Adding child controls to a KryptonGroup, KryptonHeaderGroup, or KryptonNavigator that had non-default Anchor properties values would get stuffed in the designer.

This is the first bug that was reported for release 2.0 of Krypton. Add a button inside a KryptonGroup and set the Anchor property to be Top|Bottom|Left|Right. So if the user resizes your group you get the button to grow and shrink in synch.

Everything looks good at design time, so you compile and run. Everything looks good at runtime. So you go back and reopen the form in the designer. Wow, my button just got huge!

Yep, it works fine at runtime and the FIRST time inside the designer but if you open up the designer a SECOND time it goes nuts. Well it took some time to track down and solve the problem and it highlights an irritation of mine with the designer.

It turns out that the designer does not execute the designer generated code in the same way the code is executed at runtime. This seems crazy to me, surely you would want the InitializeComponent code to run the same in either situation so you have the same scenario produced. But no, it just doesn’t work that way.

The order in which child controls are created, sized and added to the owning container are different. So I had to spend time fixing up my code so it would work in either ordering. I can only guess the difference is something to do with the designer parsing the code into a CodeDOM and then executing it.

Still, after much experimentation it seems to be working now. But I will not be completely comfortable until others have played around and found it is fine. Once I have finished fixing the current batch of bugs I will make a release so others can get their hands on it.