Archive for the ‘Krypton Toolkit’ Category

Drawing the tree nodes is much tricker than it might sound. When you perform custom drawing of the entire node it does not modify how the mouse interacts with the node itself and so you need to ensure that the drawing is aligned with the expected mouse locations. For example, when drawing check boxes I must ensure that I draw them in the exact pixel offset from the left of the control. Otherwise they will look nice but the users’ clicks will not match the drawn location and so the interaction will not work as expected.

Here you can see the drawing of check boxes and how the highlight for the selected/tracking node is immediately adjacent to the check box itself. This is not very pretty and I would prefer a pixel gap between the check box and the highlighting but this is not possible because that is the method expected by the tree control.

You can assign an ImageList to the KryptonTreeControl and then use the per-node image index to draw images by the nodes. Luckily the standard tree does have a gap between the right of the image and the node highlighting so the appearance looks tidier than for check boxes.

Also implemented is the use of the StateImageList that is used to provide an optional per-node image at the left of the node drawing. In this example I used set this up on the top two nodes only.

I honour the BackColor, ForeColor and NodeFont overrides that are defined per-node. This allows you to provide a custom look for each node to reflect status.

To make like a little easier for developers I have added a new class called KryptonTreeNode that derives from the standard TreeNode class. It adds an extra property called LongText that is an extra string that will be drawn when defined to the right of the standard node text. It also includes a LongForeColor and LongNodeFont pair of overrides allowing the l0ng text to be drawn differently.

Note that apart from the KryptonTreeNode there is no new functionality in the control. It is really just a standard TreeView with some custom drawing and so any requests for new features will not be possible. It is just a TreeView!

I have started the process of creating a Kryptonized version of the TreeView control. As with many of the Krypton controls in the Toolkit it works by using the custom drawing ability of the standard TreeView control. So it will not have any new functionality but should draw in a manner consistent with the rest of the Krypton controls.

So far I have implemented drawing the node text and the tree plus/minus nodes and lines. You can see two examples below, the first using the Office 2010 Blue palette and the second the professional palette.

Another maintenance release containing fixes for the Krypton Toolkit and Krypton Ribbon.

The biggest change is the inclusion of help for Visual Studio 2010 SP1. Note that you do need the SP1 for Visual Studio 2010 in order to see the help. If you have not already installed it then you should do so before upgrading Krypton.

Font measuring has been fixed for the Input/Message/Task dialog boxes. The Validating and Validated events are now fired for the input controls. There are four new label styles that speed up development as well as numerous crash fixes. Check out the Toolkit and Ribbon change list documents using the links below to see a full list of changes.

Download 4.3.2

Toolkit Change List
Ribbon Change List

A good suggestion turned up on the forums the other day. Why not add Bold and Italic label styles to complement the existing Normal (Control) and Normal (Panel) styles. Given that many applications need to make these small visual changes it seemed like a good idea and easy to add. So here you are…

Bold and Italic Labels

I ‘ve had a couple of bug reports for the incorrect drawing of Krypton controls when there is a deep nesting of controls under Windows 7 64bit. You can see what I mean in the following image that shows a test application that has 8 KryptonNavigator instances all inside each other.

Incorrect drawing

I spent a couple of different attempts investigating this with no luck. No matter what I did and how I looked at the scenario the Krypton code did not seem to be doing anything wrong. Fortunately someone spotted a Microsoft Knowledge Base article describing this issue and presenting a workaround. You can read it here.

The solution to the above problem was to add the following new control and then replace the 4th instance of the KryptonNavigator with the new KryptonNavigatorDelay class.

 public class KryptonNavigatorDelay : KryptonNavigator
   protected override void OnSizeChanged(EventArgs e)
     if (Handle != null)
          { base.OnSizeChanged(e); });

This results in the following appearance when resizing the window at runtime.

Correct drawing

The issue is with the operating system and seems to manifest itself under Windows 7 64bit when you have a depth of around 16 deep. Testing with various different controlsdoes not seem to make much difference in the depth required to see problems. Apparently the same problem can occur under 32bit operating systems but not until you have a much deeper level of nesting. Hence you are only likely to have encountered this problem under 64bit.

I cannot simply at the above code to every Krypton container because the solution causes a delay when drawing the control as the BeginInvoke delays execution of the delegate until the current windows message has been completed. So if you experience the issue then you need to check your nesting depth and look at implementing the work around at an appropriate level in the control hierarchy.