Expected Release Date
The release of Krypton Suite 4.0 is looking like being the middle of next week. So expect an announcement on Wednesday 26th if all goes to plan. Obviously this could slip if a major bug appears just before release but I promise it will not be released early!

Reduced Product Line-up
Something like 90% of all sales are for the full Krypton Suite and so I intend to simplify the list of product offerings by selling only the full Suite. Existing customers with the Navigator, Workspace or Ribbon that are still within their 12 month subscription will get a free upgrade to the Suite + Source. So no customers will miss out because of the change in policy.

The Suite will also only be offered with the full source code included so the ability to buy just a license is being removed. Most companies want the source code anyway and so this reduces the number of purchase options making it a simpler decision. So the purchase page is going to have just the Krypton Suite + Source with the only options being the number of licenses you want to buy.

BARGAIN ALERT: Yes, that means you could buy the Navigator at $149 before next Wednesday and get a free upgrade to the full Suite including the source code. Reading my blog means you get the inside track and your reward is a truly once in a lifetime bargain. Or why not get a 4 pack and save even more!

New Pricing
Currently the Suite + Source is priced at $399 (USD) and the new price with the docking system added will be $499 (USD). Looking at other comparable products on the market I still think this is a reasonable price given the extra flexibility and features it offers.

New Licence Options
Last is a change to provide customers with an upper limit on costs. I hope this will tempt more of the larger outfits to consider buying the Suite for the entire development department. I am introducing Site and Enterprise license options.

A Site license will allow an unlimited number of developers within your organization but limited to one geographic location. An Enterprise license allows for an unlimited number of developers at an unlimited number of locations for your organization. Customers with 16 or more licenses at the moment will be offered the chance to convert to either the Site or Enterprise depending on their licenses requirements.

Finally we can now use the mouse to drag a page header into a new position. This feature is a must for the docking system but I am sure it is helpful for those using the Navigator or Workspace standalone controls. It has been requested quite a few times over the last couple of years and finally it has made it to the top of the to-do list.

The feature works with all the Navigator modes that display elements per-page. So any of the modes that have tabs, ribbon tabs or check buttons per-page can be reordered. Even the Outlook modes have the ability as they contain a set of check buttons at the bottom of the control.

I would show some screenshots but there is no effective way of showing it working. Just wait until the docking beta 2 in a couple of week’s time and then you can play with it.

I’m currently deep in the bowels of adding docking functionality. I’ve reached the point where you can add/remove/show/hide pages on the edges of a container control. This includes docking them as well as the auto hidden feature where they slide into view when you hover over the tab stubs on the edge.

To help me out I needed to add some new events, methods and properties to the workspace and navigator controls. I thought you might find some of these handy for y0ur own applications so here is a quick summary…

KryptonWorkspace
   Methods
      HideAllPages()
      ShowAllPages()
      FirstVisibleCell()
      NextVisibleCell(…)
      PreviousVisibleCell(…)
      LastVisibleCell()
      IsCellPresent(…)
      PageForUniqueName(…)
      CellForUniqueName(…)
   Properties
      CellVisibleCount
   Events
      CellCountChanged
      CellVisibleCountChanged

KryptonNavigator
   Methods
      HideAllPages()
      ShowAllPages()
   Properties
      AllowTabSelect
      Bar.BarLastItemInset
   Events
      TabCountChanged
      TabVisibleCountChanged
      TabMouseHoverStart
      TabMouseHoverEnd

KryptonWorkspace has a new property called MaximizedCell that positions a cell to occupy the entire client area of the workspace. This allows the user to concentrate on an area of special interest for a period of time before returning to the previous layout. Here we have a simple workspace with three cells defined.

Right clicking on the Workstation tab header shows a context menu with a new Maximize option.

Selecting the option gives the following maximized layout with all but the maximized cell hidden from view.

Right click the tab header again and you will find the Maximize option has changed to become Restore instead. Keyboard users can use the shortcut Ctrl + Shift + M combination to toggle between maximized and restored.

In the examples above you can see a ButtonSpec that I added with appropriate images that allows an easier method of switching without requiring the user to discover the feature by looking at the context menu. This ButtonSpec is not added by the workspace and so if you want the same ability you will need to add it manually just as I did. You can see the new Cell Maximize + Restore sample to discover the few lines of code needed to add this capability.

Double Clicking Tabs
I’ve also added a new event to the KryptonNavigator called TabDoubleClicked which is fired whenever the user double clicks with the left mouse button on the tab header. In my new sample this is used to toggle the maximzed state but you could use this as a trigger for any default action you would like to perform.

I love the KryptonWorkspace. When you combine the flexibility of the KryptonNavigator with drag and drop positioning you have a great control. But a missing feature is the ability to persist the workspace layout so that it can be restored again. Many applications would like to save the layout when closed and reload it again at restart. Even better would be allowing the user to save multiple layouts so they can quickly switch between them as needed at the click of a button.

Persistence Formats
Use SaveLayoutToFile and LoadLayoutFromFile in order to persist to/from a file. The actual contents of the file will be an XML document but you can ignore this as modifying the contents risks making it invalid. Alternatively use the SaveLayoutToArray and LoadLayoutFromArray methods to deal with arrays of bytes. An array of bytes makes it easy to save the data into a database and so associate the layout with user’s details. Or you could convert the array of bytes into a Base64 string and include it into your own applications persistence mechanism.

There are two other formats for those needing even more options. SaveLayoutToXml and LoadLayoutFromXml use references to instances of XmlTextWriter and XmlTextReader classes respectively. So if you are already using these two classes for streaming your own data you can call into these methods and have the layout data inserted into your own XML data. Finally th SaveLayoutToStream and LoadLayoutFromStream are the most flexible and allow you to supply any Stream derived class.

Persisted Information
The hierarchy of the layout is saved starting with the Root sequence of the control. Each workspace sequence and cell is saved along with the details needed to recreate that item. Each cell can contain any number of individual KryptonPage instances, so details about each page are also saved including most, but not all, of the properties of the page. You should assume that everything about the page is saved except for two types of information. The actual set of child controls that exist on the page are not persisted and neither are the modified values of the State properties. We can see the implications of this by looking at the two likely scenarios for usage.

In the static scenario the set of pages in the workspace are going to be fixed and so every time you run your application the pages are identical. This is the easiest situation to handle.  Reloading is only expected to result in the repositioning of pages into a new layout but not cause the creation or removal of pages. You do not need to write any additional code to handle this scenario and simply calling the Save/Load methods will perform this default behavior. This is because when a page is loaded the control attempts to lookup the named page in the existing set of pages. If found it simply uses that existing page. In this static scenario the loading page will always be found and so reused.

In a dynamic scenario the set of pages could be different every time the application is run. Here you would be creating new pages depending on the users actions. Now when you load a layout you are likely to find that none of the existing pages match those being loaded. When a loading page does not match any of the existing ones then it creates a new page instance and updates the page with the loading data. Once the loading is complete it will remove any pages that are no longer required. This scenario does require you to write some additional code because the child controls on a page need to be created by the developer and are not persisted by the workspace control. Hook into the PageLoading event which is called each time a page is loaded and add the child controls as appropriate for that page (more on this below).

Customization Events
It is very likely you will want to save some additional application specific information along with the automatically generated content. To allow this use the GlobalSaving and GlobalLoading events to persist whatever arbitrary data you like. Use the PageLoading and PageSaving to persist custom data on a per-page basis.

As noted above, the PageLoading is the event used to not just recover custom data but also allow you to modify the page instance before it is used. If you have pages being created then this is where you would add the appropriate child controls and perform whatever data binding etc might be required. You can go even futher than that and assign a new page instance to the returned event data so that your assigned page is used in place of the original. It will probably be easier to create a new page in your event handler than try to customize the page provided by adding the child controls in code. Note you could assign null to the returned event data and so prevent a page being added at all. This is the technique needed to prevent a loading page from being added to the workspace, effectively ensuring the loading page is ignored as no longer required.

Our final event is fired at the end of the loading process and called PagesUnmatched. This event provides you with a list of pages that were present before the load started but were not matched with any loaded page. By default, if you do nothing then those unmatched pages will be deleted from the workspace. Hook this event if you need to examine that list of unmatched pages and instead use code to add them into the workspace again so they are not removed.

I have added a new workspace demo that shows per-page custom data being added to the persisted information so that you can see in code how easy it is.