http://blogs.msdn.com/greg_schechter/archive/2008/05/12/introduction-to-writing-effects.aspx

http://weblogs.asp.net/scottgu/archive/2008/05/12/visual-studio-2008-and-net-framework-3-5-service-pack-1-beta.aspx

Some of those effects were on Dax Pandhi’s wish list for WPF (http://blog.nukeation.com/post/My-wishlist-for-the-next-release-of-WPF.aspx) for quite some time.

More importantly, the integration of WPF and Direct3D might eliminate the need for a custom overlay control for the MenuKiller Control, which is a major performance hog (I currently use an overlay similar to this: http://blogs.msdn.com/pantal/archive/2007/07/31/managed-directx-interop-with-wpf-part-2.aspx).

Introduction

In an effort to take user experience to the next level, designers have come up with ideas on how to solve old problems in a new way. In the last few months, the term “Differentiated User Experience” or simply “Differentiated UX” has come up to describe these efforts.

One of the beforementioned UI designers is Dax Pandhi, who published an article “Rethinking the Button” on his blog which introduced a new control he calls MenuKiller. This control is certainly more than a replacement for the Menu and ContextMenu, as it can be used in ways that are quite different. However, it turns out that changing the way things are typically done is indeed not so easy.

This article gives an overview of my implementation of the MenuKiller and presents a small sample application. It’s written in C# using .NET 3.5 and Visual Studio 2008. What is presented here is not a full-fledged control, since there are quite a number of open todos. Yet, I hope that this motivates the use of different controls and serves as a good starting point for other WPF control development.

Download

The current code can be downloaded here.

Scope & Prerequsities

Since this is a custom control which is meant to redefine significant parts of user experience, it is not trivial to implement. Hence, knowledge of WPF basics is helpful, but I attempted to present the basics while still giving some more advanced tips. Although this control is merely the result of my begginer’s journey into WPF, it took me quite some time to write and it involved a lot of reading, programming and experimenting.

Also, for a better explanation of the goal we try to achieve, I strongly recommend Dax’s article. While the screenshot should already give you an idea, the article provides significantly more insight.

This control uses a very different approach to control alignment. This is the most critical point of this article. Either I did this because I was completely lost and didn’t see a better solution or this approach is a necessity of the complicated arrange behaviour this control employs. I am quite happy with the last iteration of this, before I managed to cut down code size by almost 70% through refactoring. I also dropped some ‘heavy’ features.

Design Aims

• Using the control in XAML should be very similar to using a TreeView.
• It should allow for rich and dynamic content, as well as animation.
• Databinding must be possible.
• Templating is also a requirement.
• The importance of the Visual Studio designer is low.

Our Options

When reading the MSDN on custom control authoring, Microsoft presents a lot of options on how to avoid authoring a custom control. These options include Rich Content, Styles, Data Templates, Control Templates and Triggers. Microsoft does not directly encourage you to write a control, probably in an effort to prevent people from writing controls contrary to the idea of WPF. However, I have come to the conclusion that it is best for this control to use a custom control approach, despite -or even because of- the possibilities of WPF. This control is implemented with the idea in mind that you might want to create a control which does not come with source, yet can be customized easily.

Next, it is important not to re-invent the wheel, primarily because it is error-prone and the result might not fit into the framework as it should.

So what does our control do? Essentially, it shows a hierarchically organized collection of command-bound items circularly arranged around a center object.

That does, I agree, sound a little overcomplicated, but it is the full statement. Let’s see what we can get from it:

• Hierarchically organized: Since the control presents different ‘levels’, we need to model a hierarchy. This is reminiscent of a TreeView, obviously. TreeViews are derived from ItemsControl, so we might also want to take these into account. Note that TreeViews need container objects (TreeViewItems) to store the hierarchy information while still allowing rich content.
• Circularly arranged: Since this involves solely the arrangement of items, we might want to separate this problem into a custom panel, commonly called a CircularPanel.
• around a center object: While this might look like a simple statement, it will prove to be one of the hardest tasks in the creation of our MenuKiller. Normal controls can have one of four alignments horizontally and vertically. These alignments are relative to their respective parent. The canvas, on the other hand, allows items to be positioned arbitrarily within its bounds.

The TreeView

A normal TreeView is an ItemsControl, which typically has TreeViewItems. These are, again, ItemsControls (or more specifically HeaderedItemsControls), thereby representing the desired tree structure. For our control, however, the MenuKiller itself is not an ItemsControl: It can only have one root item. Therefore, it is a ContentControl and we will not derive from TreeView.

The MenuKillerItems, on the other hand, are in fact ItemsControls, thereby being a good candidate for the parent of our MenuKillerItems. Although we won’t derive from TreeView, a small comparison of the two might be enlightening, yet keeping in mind that the behaviour of the MenuKiller is, not suprisingly, very similar to that of a normal Menu or ContextMenu.

• While the TreeView is typically used for selection purposes, a MenuKiller is used for activation of actions. This can be a button press or -toggle, depending on the CanExecute() on the Command
• Unlike TreeViewItems, Items in the MenuKiller cannot be selected. More importantly, nodes that have children are fundamentally different from those that haven’t, because they are used only for grouping purposes. (Note: It’s possible to do grouping with TreeViews, too, but that is not their default behaviour.
• Most TreeViews are embedded in a scroll container, a MenuKiller on the other hand must not live in a scroll container. It also has a much tighter constraint in terms of item count.

It is obvious that the difference between the two is rather large. I also implemented an approach using Menu and MenuItems, which have a very similar behaviour, but it turned out to be very ugly due to some render-related problems with the MenuItems.

Sizing & Positioning

The control works in a very visual manner, which requires us to have the root item in close proximity to the object it shall operate on. Let’s first concentrate on the case where the actual object does not move. Now we are still facing the problem that the control, when collapsing / expanding, changes its size. When the control grows to a certain direction -say, for example, to the top- it also needs to be repositioned, so the center of the main circle is still aligned with our object.

Even worse, since we have a hierarchical data structure, this problem must be solved for all items recursively. This, again, calls for a special panel. In an act of desperation, I called this ReferenceAlignPanel, thus qualifying for the worst-class-names-ever-thought-of-2008-award. While the name of this control is really awkward, it’s behaviour is at least unusual, too:
Given a set of controls that implement ICustomAlignedControl, it will ask the controls for their AlignReferencePoint and arrange the controls in a way such that all reference points coincide. This, of course, is not possible in every case. I stuck to a very basic implementation of this kind of panel. More on that later.

The standard ContextMenu will be placed in a Popup, and can draw on areas of the screen where the application window is not. That sounds tempting for the MenuKiller, too. However, the ContextMenu can do that only due to the fact that the ContextMenu is a very boring control with a solid background color. The MenuKiller, having a 100% transparent panel, should not cross window borders. The effect might be visually irritating.

Apart from the alignment of circles, it would be nice to see a different expanding behaviour if the control is located at a window border. It is also desireable to make a distinction between left-to-right and right-to-left systems. I call this feature “adaptive arrange”, but the current solution does not include it because some problems remain to this day. (The issue here is that we need arrangement information in the measure pass. That is not good, and the current simple MenuKiller already needs remeasures from time to time).

Summing up the possibilities on arrangement:

• We can rearrange the items in the CircularPanel in a smart manner, thus eliminating the need to use alignment hacks. This is tricky and will only work to a certain degree.
• We can put the whole MenuKiller or all MenuKillerItems into a Popup, which might result in more available space at the cost of visual coherence. This doesn’t eliminate the arrangement problem at screen borders, however. Putting each item into a separate popup is not a good idea from my experience.

For most scenarios, we can make some simplifying assumptions. The most important assumption is that there is enough space in one direction, at least. So we can choose the direction(s) with most space available as initial grow directions. We might also accept the case where the control ‘jumps’ because it grew too large in one direction, therefore requiring to be realigned, at least if there is little space available.

Custom Alignment: ICustomAlign

Let’s talk about the way our custom alignment should look for the MenuKiller: When we talk about the center of a control, we normally mean the point which lies in the middle of the actual control’s border. However, for the CircularPanel, it is desirable to know the center of the circle segment. We have to provide some public getter:

Notice that this point may be well outside of the control. The screenshot shows a CircularPanel with its full circle, the circles center and the controls center:

Since we don’t want to mess around with this interface and its alignment-implications everywhere, it’s time for the first custom panel of the solution which takes care of that:

The ReferenceAlignPanel

Also known as the panel with the ugly name, the ReferenceAlignPanel constitutes the core concept that addresses the alignment issues we are getting into by arranging all its items such that their AlignReferencePoints or their centers coincide (see above). Let me give a short introduction to panels:

When writing a custom panel, one must override the MeasureOverride and ArrangeOverride methods, which constitute the 2-pass layout system of WPF. In the MeasureOverride() method, the control is asked for its DesiredSize. WPF will automatically assign the return value of the measure pass to the DesiredSize-property. Note that even if the amount of availableSize is infinite (as it is for example in a scroll-container), you must not return an infinite size from MeasureOverride. Also, we need to make sure we call Measure() on all children:

As you can see, there are some hacks in here: We sometimes need to repeat measurement. We will later dig into that deeper; there are a number of unusual effects here.

Implementing a CircularPanel

The CircularPanel will arrange all items (more specifically, their centers or their align reference points) on a circle segment. The segments StartAngle, EndAngle and Radius can be customized using DependencyProperties, which automatically enables data binding and animation:

For the CircularPanel, the MeasureOverride() method looks like this:

First of all, note that the maximum and minimum X and Y coordinates will be used to determine the size of the resulting control. The idea here is that the CircularPanel does not need to be large enough for a full circle. You might even choose to use the CircularPanel in a different context with very large radius to achieve a completely different effect:

Note the border which is, as promised, only as large as necessary to hold the children. The circle segment which is visible is a little debugging helper. Let’s add these fancy lines and circles to the OnRender() method:

A note on this one: Using the DesiredSize, we can determine and debug whether our measure method works as expected. However, when clipped, this value will not decrease, so the border will just be clipped partially just like the rest of the control. Sice DesiredSize includes Margin, we have to subtract the value if we want to see the minimum size in this case. You also may want to draw additional Rects for debugging purposes, namely:

• Rect r = LayoutInformation.GetLayoutSlot(this); This is all available space (might be larger or smaller than DesiredSize) including Margin
• RenderSize This is all available space (again larger or smaller than DesiredSize), not including margin

A simple CircularPanel in debug mode now looks like this:

The CircularPanel provided here is still very simple, because it does not provide support realignment, re-scaling, different positioning modes, etc. However, adding that functionality is straightforward, and the panel is more elaborate than many others I found on the net. Furthermore, our CircularPanel makes some assumptions here, namely that it centers all children unless they implement the ICustomAlignedControl interface.

The MenuKillerItem

First, we have to decide whether we customize an existing control, create a UserControl or create a custom control. Since we need quite special behaviour and want the control to be re-templateable, we choose a custom control. When creating a custom control, there is no designer support (nonsense in this case, anyway) and the control will be derived from an existing control or a control base class, rather than from UserControl. A custom control will have a default template which is stored in Themes/Generic.xaml.

As previously mentioned, the MenuKillerItem will have to be an ItemsControl so it can hold a number of children. We also like it to have an Expanded property and a Header, so we derive this from TreeViewItem, where we get both of the last for free. With the components we have created before, we can start creating the core functionality of the future MenuKiller control within the MenuKillerItem. Since the whole MenuKiller has a recursive structure, most of the work is done in the MenuKillerItems, rather than in the MenuKiller class.

Additionally, we want the MenuKillerItem to report where its Header is positioned, so we have to implement ICustomAlignedControl, too.

Moreover, sticking to the approach which has a Button in its template, we need to assign a Command to the MenuKillerItem. In doing so, we expect the MenuKillerItem to be able to trigger that associated command. To do so, it needs to implement ICommandSource. Thus, our class defition reads:

Putting it together

The MenuKillerItem will consist of a Button which can be used to toggle expansion (a node), or to send a specific application command (a leaf), and a CircularPanel, which presents children if they exist and the MenuKillerItem is expanded. Since we want the Button to be in the center of the circle segment, we enclose both in a ReferenceAlignPanel, which does all the hard work for us.

Sadly, we need to know these components in the code (Footnote: This is not entirely true, at least the Button can easily be removed. For this article, I chose the simpler option, though). Therefore, we have to introduce some kind of contract between the default template defined in Generic.xaml and the code. We do this by giving those controls a special name, per convention prefixed with PART_. Let’s have a look at the MenuKillerItems default template:

Let’s take a close look at this. The first line is trivial: It creates a ControlTemplate for the MenuKillerItem. (Applying the template, however, can be a little tricky. See my blog post on this).

Everything in the control is then placed in a ReferenceAlignPanel, which will arrange the items in the desired fashion. Since we need to know this control in the code, we give it a PART_-prefix and call it PART_AlignPanel.

In the ReferenceAlignPanel, we place a Button, which we simply call PART_Button and apply a certain style to it. What the style looks like is not important right now. This merely makes sure the hover behaviour of the buttons is the same. As previously mentioned, the button does not need to be part of the generic template, but it simplifies using the control a little. Since we don’t want to restrict the contents of the button, we simply put a ContentPresenter in it which will put all content from the TreeViewItem.Header into it.

The CircularPanel is now added, again with PART_-prefix. Since we want all TreeViewItem.Items to appear in it, we set IsItemsHost to true. The Visibility, of course, shall depend on the TreeView.IsExpanded state. We’ll cover that later.

We have now created our default control template in generic.xaml, where the control has three PART_s. Here’s how we access them from code so we can use them later:

An important note: Do not use GetTemplateChild(), because it will only find direct descendants. Also refer to the MSDN Comment of GetTemplateChild(). IntelliSense should also tell you that its use is deprecated. This is a common mistake and it severly limits the extensibility and customizeability of the control.

I introduced this section with “sadly”. Why that? Well, the problem with this kind of dependency is that is somewhat error prone and hidden. It also creates a very tight coupling. However, the reasons for this lie largely in the problem domain: We need these controls to exist, otherwise the control cannot implement the behaviour it is expected to. We can at least loosen the coupling a little by providing interfaces here, that is, we don’t require a CircularPanel for example, but only an ICircularPanel which can then be re-implemented by the control user. This enhances extensibility at little cost, but here, customization is going very far.

In order to enhance visibility of this contract, there is the TemplatePart attribute, which should be applied to the class:

The attribute doesn’t change anything in terms of behaviour, but it adds meta information which is available to programs such as Expression Blend.

The code snippet above also shows the first reasons why we need to identify these controls: We want to be notified of MouseEnter and of Click events on the Button. The latter activates the command that is associated with this MenuKillerItem, or toggles expanson:

Note that there are esentially two different ways to execute the Command, depending on its type. Also note that we also implement the expansion using a custom routed command. This is convenient, since there is little overhead but it improves extensibility by providing a mechanism to programatically trigger expansion from the outside.

Custom Commands

Declaring a custom command is very easy:

However, we also need to create a CommandBinding in the static constructor of the MenuKillerItem:

The command then simply calls ToggleExpand on the target MenuKillerItem.

Expanding a Node

Now, what happens when we open a node? Essentially, we have to set the TreeViewItem.Expanded property. Databinding will the show the circular panel, and the ReferenceAlignPanel makes sure alignment is OK… But, wait a second, doesn’t that imply that the size of this control changes? Yes, but worst of all, this change propagates to the root of the tree:

Measure and Arrange in the MKI

Fortunately, since the ReferenceAlignPanel and the CircularPanel do all the gritty work for us, the MeasureOverride of the MenuKillerItem is very simple:

There is not even an ArrangeOverride! However, when a new MenuKillerItem is opened, we might want to tell it which direction it should open to. Because we can’t get that information easily, we simply have the CircularPanel notify us about its arrangements. In OnApplyTemplate, we already registered to the event. Here comes the implementation:

Opacity Issues

Next, we want to dial down the opacity of the parent control’s button and all siblings to indicate which ‘path’ is active in a visual manner. Unfortunately, there is an ‘opacity stack’, which makes it impossible to create a child element which is less transparent than its parent. So we have to come up with a little helper method:

The Tool Tip

We’re almost done!

There’s one thing left, however: The ‘tool tip’ which is presented on the center button. This is meant to provide information about the button the mouse is currently over. So there are esentially two small problems to solve here:

1. Identify the button that is under the mouse currently and retrieve its tooltip
2. Present the tool tip

To find the item that is currently under the mouse, we have to get back to our template PART_s. We already registered a MouseEnter handler in the MenuKillerItem

The event raised in here is a custom one with a very bad (i.e. misleading, already existing) name:

In order to make this available to the root MenuKiller, we have to have the MenuKiller catch the event as soon as it bubbles up and implement a DependencyProperty which makes the current ‘tool tip’ available to the outside:

As you can see, there is no template PART_ that actually displays the tool tip. This is simply because I wanted to allow rich content within the tool tip (thus it is of type object) and I believe this to be a common modification. Requiring the control user to re-template the control just to change the appearance (or worse, the position) of the tool tip seems annoying.

Finally adding the tool tip in the actual ‘users’ window markup is straightforward:

As you can see, I chose a simple TextBox, although the system allows me to use images, too. The Binding to the MenuKiller’s DependencyProperty HoverToolTip does the job, the rest is merely a description of the desired appearance. The Margin makes the TextBox appear beneath the center.

Conclusion

The MenuKiller Control offers a very different way of user interaction. With the introduction of WPF, the creation of this control has been simplified while keeping it customizeable at the same time. The use of databinding even allows to decouple parts of the control completely (e.g. tool tip box), thereby overcoming the issue of retemplating which usually requires to replace the whole template instead of replacing only specific parts.

The development of this control has taken a lof of iterations. For me, this was highly educating and a lot of fun. I hope to have contributed a little to a new discussion and new thinking in user interface design, while also providing a resource on how to develop custom WPF controls.

Open Questions, Todos

This control can certainly be optimized in various ways. There is still a lot of work to do to make this control really nice. For example, ‘adaptive arrange’ is certainly necessary in some cases, furthermore, every modification to the arrangement could be animated for some eye candy. There is a lot to do terms of features and integration with Popups, for example.

What matter most, though, is experience in using this control in a real world application. Customer and end-user feedback are required to help making this control what it is supposed to be one day: A fast, flexible, intuitive and context sensitive control with a small amount of text and happy end-user.

Resources

In the making…

History

• 2008-05-04 v. 1.0 Initial release on emphess.net

http://www.codeplex.com/prism/SourceControl/DownloadSourceCode.aspx?changeSetId=10933

The current prism drop comes with a neat documentation. Unfortunately, I won’t be able to check it out for the next few days…

The StockTraderRI now looks like this: .

This post is password protected. To view it please enter your password below:

Password: