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

I hate the Control.Visible property. It tries to do two things instead of one and so broken.

Imagine you have a Panel somewhere in your application and you add a Button onto that Panel. Set the Button.Visible to be False and then back again to True. It works exactly as you would expect by hiding the control and then displaying it again.

Now move up a level and try setting the Panel.Visible to be False so the whole Panel, including the contained Button, is hidden away. Whilst hidden try asking for the Button.Visible value and you will see it comes back with False! This is bad because it’s clearly returning a value indicating if the Button is currently visible rather than a value indicating if the Button would like to be visible. There is a big difference between those two semantics.

This problem becomes evident when you want to create your own custom layout panel. Your custom control will need to scan the set of child controls and decide how to arrange them. To make your control behave itself you want to honor the visible setting of child controls. But your stuck because asking a child control for its visible property will not always give the correct answer. If your control performs a layout when it happens to be hidden then all the children will automatically say they want to be hidden as well. Not because they really want to be invisible but purely because at the time the child control was asked the parent chain had a control that was not currently visible.

What we really need is two properties. The Control.Visible should act as an indication of the visible state the control would like to have. So the ‘get’ should return the same value as the last ’set’. Then a new property called Control.CurrentlyVisible that returns if the control is currently visible based on the state of all the parent controls up the chain of controls up to and including the owning Form.

This is something I have had to get around for the KryptonNavigator and KryptonWorkspace controls because they suffer from exactly this issue. They both have child collections of controls and need to honor the visible state of those controls. Luckily I can get around it because they can only have child controls of a type I have defined. So I can easily add the extra properties needed to those defined types. But this would fail if my collection could take any arbitrary control and not just my own types.

Here we have a brand spanking new control for the KryptonToolkit called KryptonSeparator.  It is however a very simple control that draws as an area separator and provides splitter functionality. Here you can see the control at various sizes and orientations in the Office 2008 Black scheme…

As the user moves the mouse over the control it changes the mouse cursor to indicate that it provides splitter functionality. If you press the mouse and start dragging then you see feedback drawn over the application that shows what change will occur if you release the mouse. Here you can see the visual feedback as a drag occurs…

The KryptonSeparator does not actually do anything when you release the mouse at the end of the drag as there is no way for the control to know what other controls should be resized and positioned. Instead it generates events that you can monitor and once the drag ends you use that event to decide what action to take.

The KryptonNavigator is going to be the primary container used within the docking framework for hosting docking pages. So we need to ensure we can manipulate the appearance of the navigator so it looks appropriate when inside the docking framework. By default we have the following…

I have added HeaderBarTabGroup as a new navigator mode that displays two headers around the edge of the tab headers area. As with all the header modes the buttons are placed inside the primary header instead of inside the tab bar. Switching to the new mode we get the following…

To replicate the Visual Studio 2008 docking windows we need to remove the secondary header and change the tabs orientation so they appear at the bottom. We can do that by changing a couple of existing properties. For this example I have removed the display of the context button so we have just a close button showing…

Now we have the correct layout we need to add some new palette styles so the appearance can be customized for just the docking scenario. Two new header styles called HeaderDockActive and HeaderDockInactive allow the header to indicate the active state of the navigator. The next two images show the header in each of the two styles.

Also added are a new TabBorderStyle called Dock and a tab style of Dock that allow the shape and appearance of the tabs to be defined specifically for the docking scenario. These changes give the final look and feel as follows for the Office 2007 – Blue palette…

Once I get to write the docking code there will be an event that is fired whenever a navigator is created. Just before the event is fired the navigator will be customized so it looks as seen above. But you will be able to hook into that event and alter the appearance to whatever you prefer instead. For example, you might decide to have a stacking buttons style instead. Allowing easy customization of appearance and operation are a key goal of the docking windows system.