A while ago, I came about a question posted in the (German) WPF-Forum (here's the thread). There, the poster asked for a way to connect two animated objects (residing in a Canvas control) by means of a line. While what I posted there was more like a quickie, I thought it would be fun to elaborate a bit on this, especially with respect to exactly how the line is connecting both shapes (in the post, I only introduced a way to connect the line between both objects' center points) - more on that to come.

Furthermore, I explained how to animate an object or a shape along a pre-defined path bunches of times in the forums, so this might be a good place to share my thoughts and, from now on, link to this post then instead.

 

The Basics - a very simple example

So, given an arbitrary shape, how do we create an animation that moves it from here to there? Let's start out as simple as possible; the following example will show a Rectangle that continuously moves back and forth along a horizontal line.

Assuming that we already have a Canvas control and a Rectangle within, here's the list of additional ingredients we'll need:

1. a TranslateTransform that is applied to the Rectangle's RenderTransform
2. a Storyboard that targets the Rectangle and can be run, i.e., after the Rectangle has been loaded
3. inside the Storyboard, a DoubleAnimationUsingPath - this allows to specify a Path as the source of the transform
4. a PathGeometry that we assign to the aforementioned animation and which defines the path (and thus the coordinates) that we want our Rectangle to travel along

Here's the XAML for a Window that includes all the above ingredients (click the "1. ..."-button if you're running the sample project):

 

<Window x:Class="AO_01_Simplistic"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="A simplistic sample" 
        Height="300" Width="300">
   <Window.Resources>
      <!-- The Rectangle's animation (path) -->
      <Storyboard x:Key="sb_Rect">
         <!-- The X-axis animation -->
         <DoubleAnimationUsingPath
               Storyboard.TargetName="ttAnimationTarget_Rect"
               Storyboard.TargetProperty="X" 
               Source="X"
               Duration="0:0:01"
               RepeatBehavior="Forever" 
               AutoReverse="True">
            <DoubleAnimationUsingPath.PathGeometry>
               <PathGeometry Figures="M50,0 L300,0"/>
            </DoubleAnimationUsingPath.PathGeometry>
         </DoubleAnimationUsingPath>
      </Storyboard>
   </Window.Resources>

   <!-- The Viewbox will allow to easily scale the Canvas'es contents -->
   <Viewbox Stretch="Uniform" Margin="5">
      <Border BorderBrush="DarkGray" BorderThickness="1">
         <Canvas Name="cvs" Background="#FFF0F0F0"
                    Width="450" Height="260">
            <!-- The Rectangle itself ... -->
            <Rectangle x:Name="rct" 
                          Fill="#E0ADD8E6" Width="50" Height="50"
                          Canvas.Top="100"
                          Stroke="DarkBlue" StrokeThickness="2"
                          Panel.ZIndex="1">
               <Rectangle.RenderTransform>
                  <TranslateTransform x:Name="ttAnimationTarget_Rect" X="0" Y="0" />
               </Rectangle.RenderTransform>
               <Rectangle.Triggers>
                  <!-- Start the animation as soon as the rectangle has been created -->
                  <EventTrigger RoutedEvent="FrameworkElement.Loaded">
                     <BeginStoryboard Storyboard="{StaticResource sb_Rect}"/>
                  </EventTrigger>
               </Rectangle.Triggers>
            </Rectangle>
         </Canvas>
      </Border>
   </Viewbox>
</Window>

 

And here's a little video that shows the above Window in action (don't blame me - Vimeo requires that all video-uploads are at least 200KB large, hence the long video for something as silly as that):

Here's how it works: The Rectangle's TranslateTransform (ttAnimationTarget_Rect) allows us to influence the X/Y offset that we can thus animate. Since we named the TranslateTransform, we can use it within our Storyboard-resource; in the Storyboard, we animate the TranslateTransform's X-property by means of a DoubleAnimationUsingPath which contains the path that we'd like to be followed.

 

Defining a Path (resp. its draw commands) as a resource that can be used arbitrarily

The sample above is simplistic in several ways. For instance:

• it only animates the X-axis
• it doesn't display the path that is being followed

Let's provide a more complex path (if you need more info on the draw commands' markup coming up, please refer to the docs: Path Markup Syntax and Geometries How-to Topics). Here's a shape that consists of a bunch of cubic beziers, forming a goofy path that our Rectangle can follow:

 

<PathFigureCollection x:Key="RectanglePathFigureCollection">
   M 20 50 
   C0,100 80,50 100,120
   c50,200 40,-30 200,-10
   c60,10 125,-25 0,-25
   c-20,0 -100,-10 -150,-40
   c-50,-30 -110,-55 -130,5
</PathFigureCollection>

 

Two things are worth noting here, before we continue: Instead of defining a Path along with its Data-property containing the above shapes, I created a PathFigureCollection that keeps nothing but the plain draw commands. Why that? The next subjective will be that we a) change the animation so that it considers both the X- and Y-axis which requires to state the same draw commands twice (more on that later) and b) we also want to draw the path. So, if we don't want to specify our path several times, we probably want to specify a resource and then use that instead. However, if we want to draw our shape, we'll have to specify a Geometry as the Path's Data property, but for the DoubleAnimationUsingPath's PathGeometry, we'll need to specify our shape by means of the Figure property which is a collection of PathFigure objects. Despite the fact that if, in the XAML-tags, you specify your shape as a string for both, you won't succeed in doing so when using a resource instead. You think this is weird and/or confusing? Well, it probably is ... or maybe not, because - behind the hood, (internal) converters do the trick for you when you assign the figure directly as a string in the respective property. As soon as we define a resource, however, we'll have to do that in a strongly typed fashion.

The above PathFigureCollection brings both "worlds" down to a common denominator (at the cost of a bit more markup). If we now want to refer to our shape, we'll do so by referencing the above resource for a PathGeometry's Figures property/collection (fair enough) and, for out visualized Path, we'll need to explicitly create a PathGeometry as the Path's Data-property which will then again allow us to specify the Figures property/collection (making up for the "bit more markup").

Since this shape, amongst several other things, will be used for all subsquent Windows, I created a ResourceDictionary that you'll find in the sample solution's Resources.xaml file and which contains everything that would otherwise only pollute the Windows' markup.

 

Animating a more complex shape and showing the path that is being followed

Now that we got that settled, let's (finally) move on to animating our Rectangle along the more complex shape that we defined in the last paragraph. If you recall, we only animated the Rectangle's TranslateTransform's X-property as the parth only formed a horizontal line. If we need to move in both directions though, this animation needs to target both the X- and the Y-axis. While this doesn't sound like it'd be something all too obvious, it actually is, because we only need to supply a transform in both the X- and Y-directions. Et voilá - the DoubleAnimationUsingPath does all the rest for us. Here's the XAML for the Storyboard and DoubleAnimationUsingPath that we'll use to animate the Rectangle along our goofy shape (again, you'll find this in the sample solution's Resource.xaml file):

 

<!-- The Rectangle's animation (path) -->
<Storyboard x:Key="sb_Rect">
   <!-- The X-axis animation -->
   <DoubleAnimationUsingPath
               Storyboard.TargetName="ttAnimationTarget_Rect"
               Storyboard.TargetProperty="X" 
               Source="X"
               Duration="0:0:05"
               RepeatBehavior="Forever" 
               AutoReverse="False">
      <DoubleAnimationUsingPath.PathGeometry>
         <PathGeometry Figures="{StaticResource RectanglePathFigureCollection}"/>
      </DoubleAnimationUsingPath.PathGeometry>
   </DoubleAnimationUsingPath>

   <!-- The Y-axis animation -->
   <DoubleAnimationUsingPath
               Storyboard.TargetName="ttAnimationTarget_Rect"
               Storyboard.TargetProperty="Y" 
               Source="Y"
               Duration="0:0:05"
               RepeatBehavior="Forever" 
               AutoReverse="False">
      <DoubleAnimationUsingPath.PathGeometry>
         <PathGeometry Figures="{StaticResource RectanglePathFigureCollection}"/>
      </DoubleAnimationUsingPath.PathGeometry>
   </DoubleAnimationUsingPath>
</Storyboard>

 

If you compare the above to the animation we used in the first sample Window, there's only really two (major) differences:

1. the Storyboard now contains two animations (one for the X-, one for the Y-axis)
2. the PathGeometry is now referencing the PathFigureCollection-resource that we defined earlier

And if you compare the two animations themselves, you'll see that these differ only in the axis that is being assigned. Worth noting here is the fact that you'd of course get very funny results if your two animations' Duration-, RepeatBehavior- or AutoReverse-properties differ from each other, hence always make sure that both animations only differ in the TargetProperty and Source properties!

As for drawing the shape, this can now be accomplished by adding the following to the Canvas (some additional markup omitted for clarity):

 

<Path Stroke="#200F" StrokeThickness="1">
   <Path.Data>
      <PathGeometry Figures="{StaticResource RectanglePathFigureCollection}"/>
   </Path.Data>
</Path>

 

Here's the XAML of a Window - without the resources that you'll find in the sample solution's Resources.xaml file - that now makes the Rectangle follow the goofy shape and also allows to show/hide the shape itself (watch the video underneath it to see the Window in action or click the "2. ..."-button if you're running the sample project):

 

<Window x:Class="CS.AO_02_OneObject"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="01: A single object, following a pre-defined path" 
        Width="410" Height="300">
   <Grid>
      <Grid.RowDefinitions>
         <RowDefinition Height="*"/>
         <RowDefinition Height="Auto"/>
      </Grid.RowDefinitions>

      <!-- The Viewbox will allow to easily scale the Canvas'es contents -->
      <Viewbox Stretch="Uniform" Margin="5">
         <Border BorderBrush="DarkGray" BorderThickness="1">
            <Canvas Name="cvs" Background="#FFF0F0F0"
                    Width="450" Height="260">
               <!-- The Rectangle itself ... -->
               <Rectangle x:Name="rct" 
                          Fill="#E0ADD8E6" Width="50" Height="50"
                          Stroke="DarkBlue" StrokeThickness="2"
                          Panel.ZIndex="1">
                  <Rectangle.RenderTransform>
                     <TranslateTransform x:Name="ttAnimationTarget_Rect" X="0" Y="0" />
                  </Rectangle.RenderTransform>
                  <Rectangle.Triggers>
                     <!-- Start the animation as soon as the rectangle has been created -->
                     <EventTrigger RoutedEvent="FrameworkElement.Loaded">
                        <BeginStoryboard Storyboard="{StaticResource sb_Rect}"/>
                     </EventTrigger>
                  </Rectangle.Triggers>
               </Rectangle>

               <!-- ... and the path along which it travels -->
               <Path Stroke="#200F" StrokeThickness="1" 
                     Visibility="{Binding ElementName=chkShowPaths, Path=IsChecked,
                        Converter={StaticResource boolToVisibilityConverter}}">
                  <Path.Data>
                     <PathGeometry Figures="{StaticResource RectanglePathFigureCollection}"/>
                  </Path.Data>
               </Path>
            </Canvas>
         </Border>
      </Viewbox>

      <!-- This will allow to show/hide the path along which the shape travels. -->
      <CheckBox x:Name="chkShowPaths" 
                Content="Show Path"
                IsChecked="True"
                Margin="15,5"
                Grid.Row="1"/>
   </Grid>
</Window>

 

And here's a video showing the Window in action:

 

Connecting two objects with a line

Let's introduce a second shape that has its own path to travel along. In the next Window, I added an Ellipse. I also added the Path it travels along (also an ellipse). Both the Rectangle's and the Ellipse's Path overlap each other so we can see the shapes overlap each other at times. I'll skip the XAML for the Ellipse (it's all in the sample solution) as this is more or less the same as for the Rectangle - nothing new involved there.

What I'd rather like to focus on is a third shape that I'm adding: a Line that is continuously connecting both shapes. Due to WPF's binding mechanism, this shape does not require its own animation. Instead, its end-points are simply connected to a point on each the Rectangle and the Ellipse. That is, besides the Ellipse and its (travel-) Path, all we really need to add is a single tag. Here's the markup that defines the line:

 

<!-- The line connecting both objects -->
<Line StrokeThickness="1" Stroke="Red" Panel.ZIndex="2"
      X1="{Binding ElementName=rct, Path=RenderTransform.X}"
      Y1="{Binding ElementName=rct, Path=RenderTransform.Y}"
      X2="{Binding ElementName=el, Path=RenderTransform.X}"
      Y2="{Binding ElementName=el, Path=RenderTransform.Y}"/>

 

Pretty simple, huh? Here's a video of the Window in action (click the "3. ..."-button if you're running the sample project):

Well, while the line now neatly connects both shapes, it does so by using the top left corner - probably not all that neat really, especially with respect to the Ellipse where the line is simply connecting to a (virtual) rectangle that is made up by its Width and Height properties and thus ends outside of the shape. Also (and maybe not all too obvious), the line is utilizing the RenderTransform's current coordinates only; as a result, the line would be off if we would've placed the Rectangle or Ellipse somewhere else on the Canvas (i.e. by means of Canvas.Left/Canvas.Top).

Last but not least, you might have noticed that the two shapes, while traveling along the visualized Path, do so by means of their top left corner. This really is the behavior to be expected, but it would sure look better if the shapes's center would be (or at least seemed to be) on the current position/point of the Path.

 

Making the line's end-points stick to the center of the respective object

In order to have the line's end points connect to each shape's center and, in addition to the shape's TranslateTransform's X- and Y-properties that we used to bind our line to in the previous Window, we'll now need to also consider the shape's Width And Height which will allow us to calculate the offset required to point to the shape's center. While, in the last Window, we were able to directly bind to the TranslateTransform's X- and Y-properties, we will now have to create a MultiBinding. This in turn requires that we create a Converter that takes the bindings defined in the Window's XAML and returns either the center-point's X- or Y-offset.

Here's the converter (which is actually quite simple). Note that, even though I'm showing only C# code here, you'll find all the code in VB in the sample solution's VB-project.

 

/// <summary>
/// Takes a TranslateTransform + Width & Height and calculates/returns
/// the point in the center of the shape (either X or Y).
/// </summary>
public class CenterPointConverter
   : IMultiValueConverter
{
   /// <summary>
   /// Returns either the X- or the Y-axis of the center point/coordinate 
   /// of the passed object/shape.
   /// </summary>
   /// <param name="values">
   /// This array needs to always contain three values:
   ///
   ///   - the shape's TranslateTransform
   ///   - the shape's (Actual)Width
   ///   - the shape's (Actual)Height
   /// </param>
   /// <param name="targetType">(Irrelevant)</param>
   /// <param name="parameter">
   /// The axis-coordinate to return:
   ///   "True" for X
   ///   "False" for Y
   /// </param>
   /// <param name="culture">(Irrelevant)</param>
   /// <returns>
   /// The X- or Y-value of the requested axis'es center point.
   /// </returns>
   public object Convert(
         object[] values,
         Type targetType,
         object parameter,
         System.Globalization.CultureInfo culture
      )
   {
      //
      //Also, the parameter must 
      if (values == null || values.Length != 3) return null;

      TranslateTransform tt = (TranslateTransform)values[0];
      double dblWidth = (double)values[1];
      double dblHeight = (double)values[2];
      bool fGetX = bool.Parse(parameter.ToString());

      //Calc the center of the object
      Point pt = new Point(
            tt.X + dblWidth / 2,
            tt.Y + dblHeight / 2
         );

      //Return the requested axis
      return (fGetX ? pt.X : pt.Y);
   }

   //ConvertBack skipped for clarity (empty / not implemented)
}

 

The only thing worth noting here is the fact that, after the center-point has been calculated, the Convert-method's parameter argument is being used to specify whether to return the calculated point's X- or its Y-position. Why that? Because the Line shape requires that we address each position separately (X1,Y1 + X2, Y2). Here's the XAML for our Line shape that now uses the above converter instead:

 

<!-- 
   Centering both X1/Y1 and X2/Y2 so they're in the center of the 
   respective object 
-->
<Line StrokeThickness="1" Stroke="Red" Panel.ZIndex="2">
   <Line.X1>
      <MultiBinding Converter="{StaticResource centerPointConverter}"
                    ConverterParameter="True">
         <Binding ElementName="rct" Path="RenderTransform"/>
         <Binding ElementName="rct" Path="Width"/>
         <Binding ElementName="rct" Path="Height"/>
      </MultiBinding>
   </Line.X1>
   <Line.Y1>
      <MultiBinding Converter="{StaticResource centerPointConverter}"
                    ConverterParameter="False">
         <Binding ElementName="rct" Path="RenderTransform"/>
         <Binding ElementName="rct" Path="Width"/>
         <Binding ElementName="rct" Path="Height"/>
      </MultiBinding>
   </Line.Y1>
   <Line.X2>
      <MultiBinding Converter="{StaticResource centerPointConverter}"
                    ConverterParameter="True">
         <Binding ElementName="el" Path="RenderTransform"/>
         <Binding ElementName="el" Path="Width"/>
         <Binding ElementName="el" Path="Height"/>
      </MultiBinding>
   </Line.X2>
   <Line.Y2>
      <MultiBinding Converter="{StaticResource centerPointConverter}"
                    ConverterParameter="False">
         <Binding ElementName="el" Path="RenderTransform"/>
         <Binding ElementName="el" Path="Width"/>
         <Binding ElementName="el" Path="Height"/>
      </MultiBinding>
   </Line.Y2>
</Line>

 

Repositioning the visualized Path

Alright, we now achieved that the Line shape will always end in both the Rectangle's and the Ellipse's center. As I mentioned earlier, the DoubleAnimationUsingPath will continuously position our shapes at a given coordinate of the defined Path; since we target the TranslateTransform however, this will always be the respective shape's top-left corner. While we could, of course, introduce another converter that would take the TranslateTransform and again calculate the offset required to position our Rectangle and Ellipse with their center on the visualized path, let's rather shift the visualized Path instead. The technique here is just the same as the one we've been using to animate the Rectangle and Ellipse - we simply apply a TranslateTransform. But this time, we'll apply it to the Path's RenderTransform directly (we don't want this to be animated). Here's the Rectangle's Path that the Rectangle travels along (the one for the Ellipse only differs in the Element-binding and is otherwise identical):

 

<Path Stroke="#200F" StrokeThickness="1" 
      Visibility="{Binding ElementName=chkShowPaths, Path=IsChecked,
      Converter={StaticResource boolToVisibilityConverter}}">
   <Path.Data>
      <PathGeometry Figures="{StaticResource RectanglePathFigureCollection}"/>
   </Path.Data>
   <!--
      The following Transform will allow to draw the path based on the
      center of the Rectangle that follows it.
   -->
   <Path.RenderTransform>
      <TranslateTransform
         X="{Binding ElementName=rct, 
            Path=ActualWidth, 
            Converter={StaticResource divideBy2Converter}}"
         Y="{Binding ElementName=rct, 
            Path=ActualHeight, 
            Converter={StaticResource divideBy2Converter}}"/>
   </Path.RenderTransform>
</Path>

 

Again, the only thing worth noting here is the fact that another converter is required in order to divide the Width/Height by 2 to get the required offset for X/Y. Since the converter is so simple, it has been omitted here (you'll find it in the sample solutions Converters.cs/Converters.vb file). If you plan to use the DivideBy2Converter, please note that it doesn't consider any object displacement, i.e. the offset defined if your object is placed in a Canvas by means of the Canvas.Left/Canvas.Top attached properties as this would really require the use of a MultiBinding along with an IMultiValueConverter and thus have "polluted" the XAML.

Here's the next video of a Window in action which contains all of the above (click the "4. ..."-button if you're running the sample project):

 

Making the line stick to the perimeter center of the respective object

At this point, we actually have a nicer/cleaner version of the quick hack I posted in the forum-thread that I mentioned at the beginning, but not all too much that would go beyond (except for a few littleties). However, I thought I'd rather like the Line connect to the perimeters of both shapes. That is, there's two possible scenarios that I think could be used for i.e. charting or the such:

• connecting two objects with the shortest line possible

and 

• connecting between both object's center points, but with the line ending at the shape's perimeter.

Maybe I'll have another go in the future at the first alternative, but for the time being, I went for the latter one which imposed one of those little mathematical challenges that I like wrapping my head around.

Since, for the remainder of this section, we'll focus on the code required to calculate the perimeter points, here's a little excerpt of how the converter - that I'll introduce further down - needs to be used on the XAML-side. Note that, due to the verbosity, I'm showing only the Line's X1-part. The XAML for Y1, X2 and Y2 only differs in the ConverterParameter and/or in the ElementName-binding (reversing the order of appearance of the two shapes), so I guess it makes more sense to only post the relevant excerpt:

 

<Line.X1>
   <MultiBinding Converter="{StaticResource twoShapesPerimeterConverter}"
                 ConverterParameter="True">
      <Binding ElementName="rct"/>
      <Binding ElementName="rct" Path="RenderTransform"/>
      <Binding ElementName="el"/>
      <Binding ElementName="el" Path="RenderTransform"/>
      <Binding RelativeSource="{RelativeSource Self}"/>
   </MultiBinding>
</Line.X1>

 

As you can see in the XAML above, we now need to pass 5 parameters to the TwoShapesPerimeterConverter-converter. That is, we need each shape itself along with its RenderTransform plus the Line-shape. Since I'm passing a reference to each shape, you might ask yourself as to why the RenderTransform is being passed along. The reason is that the binding-mechanism (or rather INotifyPropertyChanged) is smart enough to only call into the converter if a relevant value changes. This "smartness" of course is necessary as, otherwise, the converter would be called over and over again, even if nothing changed that would justify the call in the first place. So, while that really is a good thing, it forces us to not only pass a reference to the shape in question (using which we could of course get at the RenderTransform), but also the RenderTransform. If we wouldn't, the converter wouldn't be called when it should.

Now that we sorted that out, let's look at the code. Before I do, let me once again point out that, even though I'm showing only C# code here, you'll find all the code in VB in the sample solution's VB-project. Also, I'll start with the main body of the Convert-method, skipping parts that I'll get to later:

 

public object Convert(
		object[] values,
		Type targetType,
		object parameter,
		System.Globalization.CultureInfo culture
	 )
  {
	 if (values == null || values.Length != 5) return null;

	 //First shape
	 FrameworkElement fe_O1 = (FrameworkElement)values[0];
	 TranslateTransform tt_O1 = (TranslateTransform)values[1];
	 double dblWidth_O1 = fe_O1.Width;
	 double dblHeight_O1 = fe_O1.Height;
	 //Second shape
	 FrameworkElement fe_O2 = (FrameworkElement)values[2];
	 TranslateTransform tt_O2 = (TranslateTransform)values[3];
	 double dblWidth_O2 = fe_O2.Width;
	 double dblHeight_O2 = fe_O2.Height;
	 //The connecting line
	 Line lne = (Line)values[4];
	 //Whether to return the X- or Y-axis
	 bool fGetX = bool.Parse(parameter.ToString());

	 double dblOffset_X_O1 = 0;
	 double dblOffset_Y_O1 = 0;
	 double dblOffset_X_O2 = 0;
	 double dblOffset_Y_O2 = 0;

	 //We're assuming that the control is part of a canvas, 
	 //so retrieve its position. 
	 //This will, however, only work if Canvas.Left/Canvas.Top 
	 //have been set, so check first.
	 if (!double.IsNaN(Canvas.GetLeft(fe_O1)))
		dblOffset_X_O1 += Canvas.GetLeft(fe_O1);
	 if (!double.IsNaN(Canvas.GetTop(fe_O1)))
		dblOffset_Y_O1 += Canvas.GetTop(fe_O1);

	 if (!double.IsNaN(Canvas.GetLeft(fe_O2)))
		dblOffset_X_O2 += Canvas.GetLeft(fe_O2);
	 if (!double.IsNaN(Canvas.GetTop(fe_O2)))
		dblOffset_Y_O2 += Canvas.GetTop(fe_O2);

	 //Calc the center of the first object
	 Point ptCenter_O1 = new Point(
		   dblOffset_X_O1 + tt_O1.X + dblWidth_O1 / 2,
		   dblOffset_Y_O1 + tt_O1.Y + dblHeight_O1 / 2
		);

	 //Calc the center of the second object
	 Point ptCenter_O2 = new Point(
		   dblOffset_X_O2 + tt_O2.X + dblWidth_O2 / 2,
		   dblOffset_Y_O2 + tt_O2.Y + dblHeight_O2 / 2
		);

	 //The point of which we'll return either X or Y.
	 //In case anything goes wrong, we'll simply return 
	 //a point that is negative and thus hopefully out of view.
	 Point ptPerimeterIntersection = new Point(-1000, -1000);

	 //Calculate the point on the first shape's perimeter,
	 //according to the type passed.
	 string strType = fe_O1.GetType().Name;
	 switch (strType)
	 {
		case "Rectangle":
		   [...]
		   break;

		case "Ellipse":
		   [...]
		   break;

		default:
		   //Oops.
		   throw new NotSupportedException("Unsupported type \"" + strType + "\".");
	 }

	 //Only show the line, if the resulting point is outside of the object, hide it
	 lne.Visibility = (ptPerimeterIntersection.X < 0 || ptPerimeterIntersection.Y < 0 ? Visibility.Hidden : Visibility.Visible);

	 //Return the requested axis
	 return (fGetX ? ptPerimeterIntersection.X : ptPerimeterIntersection.Y);
  }

 

There shouldn't anything overly surprising in the above: the converter first assures that the expected number of arguments has been passed, casts them into strongly typed variables, does a few calculations (to again get both shapes' the center-points) and then finally gets to its "heart" (more on that to come), i.e. the stuff represented by the [...]-placeholders. There's only three things worth noting here:

1. Other than with the previously introduced converters, this one now considers a potentially existing offset applied to the shape by means of Canvas.Top/Canvas.Left.
2. The switch-statement (Select Case in VB) is based on the name of the passed shape's type to determine what math is to be applied (see below for the math itself).
3. The point that we return X or Y for defaults to a location outside of view, so that, if the respective shape's calculation doesn't return a valid value (which would be the case if both shapes overlap each other), the Line can be hidden.

As you can see, I only considered two general types of shapes: a Rectangle and an Ellipse. I'm not really planning on adding more shapes (this is purely academic really - I have no use for this at present), but this would be the place where you'd add the math for other types.

Before we peek at both shapes and the math required to get a point on their perimeter, let me send ahead that the center-points are still the basis for all calculations to follow. That is, first a virtual line will be considered that connects between both shapes' center points, then this line is "shortened" so that it ends on the center of the perimeter (or the center of the shape's stroke) of the first object that has been passed into the converter. This virtual line is actually the reason for the necessity of passing both shapes into the converter.

 

Calculating the perimeter-point for the Rectangle

For the Rectangle, the code in the converter is quite short, but the reason really is that it requires a) repetetive calls to identical code and b) contains generic code that could be used somewhere else, hence I put this into a separate class. FWIW, here's the code that makes up for the previous snippet's [...]-placeholder:

 

Rectangle rct = (Rectangle)fe_O1;
//Create a line that connects both objects' center points.
Line lneConnector = new Line()
{
  X1 = ptCenter_O1.X,
  Y1 = ptCenter_O1.Y,
  X2 = ptCenter_O2.X,
  Y2 = ptCenter_O2.Y
};
Rect r = new Rect()
{
  X = dblOffset_X_O1 + tt_O1.X,
  Y = dblOffset_Y_O1 + tt_O1.Y,
  Size = new Size(rct.ActualWidth, rct.ActualHeight)
};
//The calculations are quite verbose, hence I placed them in a helper-class.
//See the below method's definition for more information.
ptPerimeterIntersection = Helpers.RectAndLineIntersectionPoint(r, rct.StrokeThickness, lneConnector);
break;

 

So all we do here is to prepare the arguments that the RectAndLineIntersectionPoint() method expects. These consist of a rect-structure (which contains all information required about our Rectangle), the Rectangle's StrokeThickness (which we need in order to return a point that sits in the center of the stroke) and a Line that connects the Rectangle itself with our second end-point which really is the center of an arbitrary other shape (the Ellipse in our sample Window).

Here's the RectAndLineIntersectionPoint() method (minus the header comments):

 

public static Point RectAndLineIntersectionPoint(
	Rect rct, 
	double dblRectStrokeWidth, 
	Line lne
 )
{
 Point ptIntersection = new Point(-1000, -1000); //Default: outside of visible area
 double RO = dblRectStrokeWidth / 2; //Offset required due to the Rectangle's stroke-width 

 //We'll need to test the four sides of the Rectangle
 Line lneRect_Top = new Line() { X1 = rct.Left + RO, X2 = rct.Right - RO, Y1 = rct.Top + RO, Y2 = rct.Top + RO };
 Line lneRect_Bottom = new Line() { X1 = rct.Left + RO, X2 = rct.Right - RO, Y1 = rct.Bottom - RO, Y2 = rct.Bottom - RO };
 Line lneRect_Left = new Line() { X1 = rct.Left + RO, X2 = rct.Left + RO, Y1 = rct.Top + RO, Y2 = rct.Bottom - RO };
 Line lneRect_Right = new Line() { X1 = rct.Right - RO, X2 = rct.Right - RO, Y1 = rct.Top + RO, Y2 = rct.Bottom - RO };

 if (!Helpers.DoLinesIntersect(lneRect_Left, lne, ref ptIntersection))
	if (!Helpers.DoLinesIntersect(lneRect_Top, lne, ref ptIntersection))
	   if (!Helpers.DoLinesIntersect(lneRect_Right, lne, ref ptIntersection))
		  if (!Helpers.DoLinesIntersect(lneRect_Bottom, lne, ref ptIntersection))
			 return new Point(-1000, -1000);

 return ptIntersection;
}

 

Here's how it works: in order to find the side that the also passed line intersects, we'll have test each of the Rectangle's sides separately. For the order of the tests/sides, I opted to follow the same approach as with i.e. the Margin attached property does - starting on the left and then going on clockwise to the bottom, stopping the calculations as soon as the first intersection point has been found. I know I could've created the Line-objects only when required, too, but this is one of the occasions where I prefer readability over performance (I didn't do any perf tests to see what the cost really is). The separate Line objects being created, BTW, are solely for the purpose of considering the StrokeThickness and thus calculating the offset we need. That is, the rect-structure is simply reduced by half of the StrokeThickness on each side so that the DoLinesIntersect()-method can operate on the values required to return a point in the center of the stroke.

I won't discuss the code behind the DoLinesIntersect()-method as I simply took this method over from somebody else and converted it into a C# and VB-version. For more information, see the source code in the sample solution (you'll find the above method as well as the DoLinesIntersect()-method in Helpers.cs/Helpers.vb). You can also refer to the Paul Bourke's site where I took the math from: Intersection Point Of Two Lines (2 Dimensions). Thanks from here go out to Paul and the folks that kindly provided the source-code in C/C++ which I used for my C#/VB versions.

 

Calculating the perimeter-point for the Ellipse

So, here goes the last code-snippet which calculates the point on the Ellipse's perimeter that is being intersected by the line traveling between the Ellipse's and the other shape's center points:

 

Ellipse el = (Ellipse)fe_O1;
double dblEllipse_Radius_X = (el.ActualWidth - el.StrokeThickness) / 2;
double dblEllipse_Radius_Y = (el.ActualHeight - el.StrokeThickness) / 2;

//Create a vector for each a flat X- and one for X- and Y-axis - this will
//allow us to calculate the angle of a virtual line connecting the 
//center-points of both objects.
Vector v1 = new Vector(0, ptCenter_O1.Y - ptCenter_O2.Y);
Vector v2 = new Vector(ptCenter_O2.X - ptCenter_O1.X, v1.Y);

//If the second object is left of the ellipse, we'll need to return
//a point on the left half of the ellipse; if not, the perimeter-point 
//will be on its right half.
bool fIsOnLeftHalf = (ptCenter_O2.X < ptCenter_O1.X);

//Get the angle between both vectors
double dblAngle_GRAD = Vector.AngleBetween(v2, v1);

//The Vector.AngleBetween will return a value in degrees (and shifted 90° to the right
//due to the different coordinate-system that with 0° "in the east"), but we'll need 
//the value in radians for the calculations coming up, so convert the value accordingly.
double dblAngle_RAD = (Math.PI * (dblAngle_GRAD - 90d)) / 180d;

//In order to have this work not only for a circle, but also for an ellipse,
//will have to consider both radii (major/minor).
double theta = Math.Atan((dblEllipse_Radius_X / dblEllipse_Radius_Y) * Math.Tan(dblAngle_RAD));
double x = ptCenter_O1.X + dblEllipse_Radius_X * Math.Cos(theta) * (fIsOnLeftHalf ? -1 : 1);
double y = ptCenter_O1.Y + dblEllipse_Radius_Y * Math.Sin(theta) * (fIsOnLeftHalf ? -1 : 1);

//The above will, due to the usage of vectors, not consider whether or not the line is traveling
//through the perimeter, so test whether the calcuated point of the 2nd object lies within the 
//ellipse. Since, further down, we'll be testing as to whether the found point is located
//beyond the visible area (which is the perimeter-point's current value), only assign the
//found point if it is outside of a "virtual" (!) ellipsis defined with the center-point being
//the 2nd object's center - we cannot test with the "real" ellipsis itself since the point is
//ON but not OUTSIDE of the ellipse.
Point ptTemp = new Point(x, y);
if (!Helpers.ContainsPoint(ptCenter_O2, dblEllipse_Radius_X, ptTemp)
	 && !Helpers.ContainsPoint(ptCenter_O2, dblEllipse_Radius_Y, ptTemp))
  ptPerimeterIntersection = ptTemp;
break;

 

I sort of wondered as to why I couldn't find anything on the web for this (should really be something somebody else has done I thought). But well, that part was the most fun (and my personal challenge) anyway, so here's how I went about this.

Taking the Ellipse's radii (major and minor, that is), two Vectors are created that, in turn, allow us to simply utilize the Vector-class'es AngleBetween()-method to calculate the angle of the (virtual) line that connects our Ellipse with the other object (from center to center). Once we have the angle, we need to a) shift it counter-clockwise by 90° (due to .Net's coordinate system starting at 90°/"east") and then convert it back into radians (which is what we'll need for the trigonometry functions). Using the arctangent we can then calculate the X- and Y-coordinates of our point on the perimeter using the ubiquituous sinus/cosinus functions. Since the resulting point will always be on the right half of our Ellipse, a little check will simply multiply the result with -1 if it detects that we need to target the Ellipse's left half. The only thing left to do after the point has been found is to check as to whether our virtual line ends inside the ellipse (and is thus not intersecting its perimeter) in which case we don't want to show the line at all (which again we do by not setting the perimeter-point). To do the check, the code simply checks whether the calculated center-point of the second/other shape is residing within the Ellipse.

 

Wrapping it all up

Here's a video with a Window in action that again contains all of the above (click the "5. ..."-button if you're running the sample project):

 

The last word

As I said, this really was a nice way to waste my time - I don't have any scenario in which I think I could use the stuff introduced here (which is probably why it's been so much fun). That having been said, I'd sure like to know if you find a scenario for which this actually would be useful. Also, my math is problably not the best, so if you think that there would be an easier approach to do the calculations (or just a different one), make sure you drop a comment!

 

The sample solution

I’ve created a sample solution that contains everything discussed here, containing one project for each the C# and the VB versions.

Download: AnimatingObjectsAlongAPath.zip (54.47 kb)

Location: PostList

Introduction

The previous article left us with a TabControl featuring animated TabItems. Today, I'd like to present another couple of extensions to that TabControl. These include a custom TabPanel which will no longer wrap its TabItems when these won't fit onto a single row and a menu that'll present all TabItems' header-text, allowing users to quickly navigate to a TabItem.

 

Overview

This article is part of a multi-part series. Here's the four parts of the series:

• WPF: TabControl Series - Part 1: Colors and Sizes
• WPF: TabControl Series - Part 2: Animating the TabItems
• WPF: TabControl Series - Part 3: Non-wrapping TabItemPanel (this article)
• WPF: TabControl Series - Part 4: Closeable TabItems

 

Outcome: the result of what's covered in this article

Here's what we'll be left with at the end of this article:

 

Status quo (after Part Two)

As noted before, this article is based upon the stuff I introduced in the other parts, hence I'll simply assume that you read and understood what has been discussed there. Please see the other parts in case you find that I am assuming something you don't see discussed here.

Here's where we'll start in this part, that is, what the TabControl and its "sub-controls" looked like at the end of Part Two:

If you downloaded the sample solution (see the bottom for the link), click the "1. Base-style (animated, without ScrollViewer)" button to show the above window.

Before we start

In the previous parts, I always refered to the panel that contains the TabItems as the TabItemPanel. Actually I don't have the slightest idea as to why I called it like that (I'm getting old I guess - I promise I didn't have too much beer!). Of course, the control's name is TabPanel! I don't know for sure whether I'll update Part One and Part Two accordingly, but since this would require to change the solutions along the way, I'll leave everything "as is", at least for the time being (but I slapped myself for being stupid, if that's OK with you). For this article however, I changed the source code to refer to the control by its correct name instead and this paragraph is the last one where you'll see the term TabItemPanel - promised. So, if you actually follow along with your own code, you might want to do a find & replace.

 

The problem with what we have at this point

While the style provided in Part Two actually contains a "control" that could be used as is, it imposes quite a major drawback if the TabItems' width exceeds the width of the TabPanel. In this case, the TabPanel (which is what is being used up to this point) will wrap its items, leaving you with something more or less like this (click to enlarge):

 

Gee, not really what I'd consider a nifty appearance, huh? Also, the TabPanel will constantly rearrange the TabItems when the SelectedItem changes. This is what I hate very much about i.e. the Options dialogs in Office (like Word).
In the remainder of this part, I'll hence show you how to work around this by (basically) allowing users to scroll the TabPanel instead.

 

Enter the ScrollViewer

Whenever you're in the situation where you need like to display content that could possibly exceed the size of the hosting control (or the size that that control can take in your UI), the ScrollViewer control will most probably be part of your solution to the task. The ScrollViewer is what allows to actually have a "virtual area" that extends beyond the size of your control. Let's consider a simple sample:

In the above image, the black rectangle represents the control as it is being rendered in the UI. The gray rectangle, however, represents the area that would be required in order to completeley render all content in the control. In a scenario like this, theScrollViewer control will allow us to automatically display ScrollBar controls for the X and/or Y axis if the content exceeds the size of the control. The schema above also shows the definition for the two "areas" that exist in the ScrollViewer control:

• the area that is being rendered by the control is refered to as the Viewport of the control
• the "virtual area" that makes up for the size as desired by the elements contained within is refered to as the Extent of the control

Now, whenever the control's Extent gets larger than the Viewport, the ScrollViewer will display either horizontal and/or vertical scrollbars; unless you tell it not to, that is. For our specific case, we want the scrolling behavior that the ScrollViewer offers, but we sure don't want the ScrollBars, do we! More on that later.

 

How to enable scrolling

Now what do we need in order to allow our TabPanel to rather scroll when there's more TabItems than we would be able to fit onto a single row? Actually, this is as simple as wrapping your content-control into a ScrollViewer:

<ScrollViewer SnapsToDevicePixels="True"
              HorizontalScrollBarVisibility="Auto" 
              VerticalScrollBarVisibility="Disabled">
   <TabPanel ...>
</ScrollViewer>

The above would already be sufficient in order to force the TabPanel to rather scroll than to wrap TabItems. Also, by setting the VerticalScrollBarVisibility to Disabled, we tell the control to never show the vertical scrollbar.
Well, the above would leave us with a H-ScrollBar popping up when the overall width of all TabItems would exceed the width of the TabPanel and we sure don't want that (or is it a matter of personal preference?). In order to gain more control over what happens when the Extent exceeds the Viewport, the Horizontal-/VerticalScrollBarVisibility properties (which actually refer to the ScrollBarVisibility enumeration) also allow us to set two other values: Visible and Hidden. While Visible will make the control show the respective ScrollBar all of the time, Hidden will never display it. Now what's the difference between Hidden and Disabled? If we set this to Disabled, scrolling will not be possible at all; instead, the size of the control would be extended as long as the UI leaves room for the extension or, if that's not possible, the remainder would simply remain invisible and thus would never be seen.

We really don't want any ScrollBar at all, but rather provide our own buttons to allow for scrolling. That is, two buttons - one for each scrolling to the left and right - will provide the same functionality as the LineButtons (the arrow-buttons on the far left/right resp. top/bottom) do. As a result, let's make a few changes to the XAML above.

 

Exit the TabPanel

While changing the XAML, let's go ahead and get rid of the TabPanel along the way, replacing it with its simpler counter part - the StackPanel. Why that? Comparing the StackPanel to the TabPanel, the latter one really only provides two things that the StackPanel doesn't:

1. it wraps TabItems in rows when required
2. it rearranges TabItems when the selected TabItem changes, i.e. assures that the selected TabItem is on the bottom row (actually, that's probably the only difference between the TabPanel and the WrapPanel ...)

We don't need either of those two - all we need is an area that can scroll in one direction, so a StackPanel with Orientation="Horizontal" will provide all we need.

As a result, this would leave us with the following:

<ScrollViewer SnapsToDevicePixels="True"
              HorizontalScrollBarVisibility="Hidden" 
              VerticalScrollBarVisibility="Disabled">
   <StackPanel ...>
</ScrollViewer>

After applying the above change to the XAML of what we finished with in Part Two, we get this (click for a larger image):

If you downloaded the sample solution (see the bottom for the link), click the "2. Standard ScrollViewer added" button to show the above window.

In the XAML for the above window, I added some more TabItems (there's now 15 of them) and, as you can see, the TabPanel no longer wraps. Kewl.
However, while you can loop through the TabItems with the arrow keys, there's no way of getting to the TabItems using the mouse.
If you watched the video in the introduction of this article, you will have seen what I really had in mind was an area to the right of the TabPanel in which the LineButtons (aka the scroll buttons) are placed.

 

Hosting the ScrollButtons

So where do we place the ScrollButtons? It's actually not as easy as you'd think. If you look at the last screenshot again, you'll see that the first tab is missing its leftmost part. One of the reasons for this is the negative (horizontal) margins that are applied by the triggers of the selected TabItem (-4 in the sample). That is, remember that we (err, I ) wanted the selected TabItem to overlap into the adjacent TabItems' "territory" (hey, are those Saddam-tabs? These are successful though!)? In the present situation, this forces us to do quite a substantial amount of additional work. Also, we still want to have the borders be displayed right (see Part One). While there is several possible approaches to all this, I opted to override the ControlTemplate of the ScrollViewer control (not least because this is also a tutorial about the power of styles!). Overriding the ControlTemplate again gives us all the flexibility we need (well, not all exactly, but more on that later).

Here's the part of the XAML that contains the definition/setup of the TabPanel along with the ScrollViewer in which has now been wrapped:

<Border Name="TabPanelBorder"
                             Height="35"
                             Background="{StaticResource TabPanel_BackgroundBrush}">
   <ScrollViewer SnapsToDevicePixels="True"
                                      Name="svTP"
                                      Grid.Row="0"
                                      HorizontalScrollBarVisibility="Hidden" 
                                      VerticalScrollBarVisibility="Disabled">
      <ScrollViewer.Style>
         <Style TargetType="{x:Type ScrollViewer}">
            <Setter Property="Focusable" Value="False"/>
            <Setter Property="Template">
               <Setter.Value>
                  <ControlTemplate>
                     <Grid SnapsToDevicePixels="True" 
                                                Grid.Row="0" Grid.Column="0">
                        <Grid.ColumnDefinitions>
                           <!-- 
                              The TabItems (resp. the TabPanel)
                              will appear here 
                           -->
                           <ColumnDefinition Width="*"/>
                           <!-- 
                              The following two columns will host
                              the Scrollbuttons 
                           -->
                           <ColumnDefinition Width="Auto"/>
                        </Grid.ColumnDefinitions>
                        <ScrollContentPresenter 
                           x:Name="PART_ScrollContentPresenter"
                           VirtualizingStackPanel.IsVirtualizing="False"
                           SnapsToDevicePixels="True" 
                           Grid.Column="0" 
                           Content="{TemplateBinding ScrollViewer.Content}"/>
                        <Grid x:Name="gScrollButtons" 
                              HorizontalAlignment="Right"
                              Grid.Column="1">
                           <Grid.RowDefinitions>
                              <RowDefinition Height="*"/>
                              <RowDefinition Height="Auto"/>
                           </Grid.RowDefinitions>
                           <StackPanel Grid.Row="1"
                                 Orientation="Horizontal"
                                 Margin="{StaticResource 
                                    TabPanelScrollPanel_Margin}">
                              <!-- 
                                 The two RepeatButtons below will actually provide
                                 the scroll-functionality for the TabItems. 
                                 Here, I'm utilizing the Page[Left/Right]Command; 
                                 This could as well be using the 
                                 Page[Left/Right]Command instead.
                              -->
                              <RepeatButton 
                                 Style="{StaticResource LineButtonStyle}"
                                 Command="ScrollBar.PageLeftCommand"
                                 Content="{StaticResource ArrowLeftPath}"
                                 IsEnabled="{Binding ElementName=svTP, 
                                    Path=HorizontalOffset, 
                                    Converter={StaticResource 
                                    scrollbarOnFarLeftConverter}}"/>
                              <RepeatButton 
                                 Style="{StaticResource LineButtonStyle}"
                                 Command="ScrollBar.PageRightCommand"
                                 Content="{StaticResource ArrowRightPath}">
                                 <RepeatButton.IsEnabled>
                                    <MultiBinding Converter="{StaticResource 
                                          scrollbarOnFarRightConverter}">
                                       <Binding ElementName="svTP" 
                                          Path="HorizontalOffset"/>
                                       <Binding ElementName="svTP" 
                                          Path="ViewportWidth"/>
                                       <Binding ElementName="svTP" 
                                          Path="ExtentWidth"/>
                                    </MultiBinding>
                                 </RepeatButton.IsEnabled>
                              </RepeatButton>
                           </StackPanel>
                        </Grid>
                     </Grid>
                     <ControlTemplate.Triggers>
                        <DataTrigger Value="false">
                           <DataTrigger.Binding>
                              <MultiBinding Converter="{StaticResource
                                    scrollbarOnFarRightConverter}">
                                 <Binding ElementName="svTP" 
                                    Path="HorizontalOffset"/>
                                 <Binding ElementName="svTP" 
                                    Path="ViewportWidth"/>
                                 <Binding ElementName="svTP" 
                                    Path="ExtentWidth"/>
                              </MultiBinding>
                           </DataTrigger.Binding>
                        </DataTrigger>
                     </ControlTemplate.Triggers>
                  </ControlTemplate>
               </Setter.Value>
            </Setter>
         </Style>
      </ScrollViewer.Style>
      <!-- 
         This is the area in which TabItems (the strips) 
         will be drawn. 
      -->
      <StackPanel Name="TabPanel"
		 Orientation="Horizontal"
		 IsItemsHost="true" 
		 Margin="{StaticResource TabPanel_Padding}"
		 KeyboardNavigation.TabIndex="1"/>
   </ScrollViewer>
</Border>

Here's the deal: The ScrollViewer contains a Grid with two columns. Let's start with the second column. Here, another Grid (gScrollButtons - named only for the sake of clarity) contains two rows - the top one will remain empty and take whatever the remainder of the overall height leaves; the second will contain a StackPanel with two RepeatButtons (thus allowing for continuos scrolling while holding down the mouse-button - you'll find these in the ScrollBar control, too). Using two rows is just one way of aligning the StackPanel to the bottom so that it's right above the content area of the TabControl. In order to make the RepeatButtons actually perform scrolling, a simple CommandBinding does the trick. That is, the ScrollViewer control exposes commands for scroll-operations such as LineLeft or PageLeft (+ the adequate ones for Right/Up/Down), ScrollToLeftEnd (and various others to scroll to all edges of the Extent), and another bunch for scrolling for the MouseWheel. In the sample above, I opted to utilize the PageLeft/PageRight commands.

In the first column in the ScrollViewer's (main) grid - which will use the remainder of the horizontal extent - you'll find the ScrollContentPresenter. This is the control that actually represents the content to be rendered in the control, aka the Viewport. To make the ScrollViewer render its content in the ScrollContentPresenter, we simply (template-) bind its content to that of the ScrollViewer (TemplateBinding ScrollViewer.Content).
(The reason for the above XAML looking a "bit" clunky is actually really because I wrapped it into many lines so the code-formatter that I'm using doesn't get upset with me ...)

Geometries, Paths, Converters

If you looked closely at the XAML, you probably saw that there's two converters and Path-resources for rendering the buttons' content.
Regarding Geometries - I usually have a whole bunch of those in a ResourceDictionary (or several of them) so that I can use them a) with themes (i.e. different paths for different themes) and b) simply reference them throughout applications. Another  advantage is that - since we're really defining vectors - we can make them (well, paths that use their data) scale inside whatever content-control we use them in, without any loss or pixelation, when they need to grow larger (we Germans don't fancy six-packs, so a crate of beer to whoever came up with that!).

The Path resources are really two-fold; first, there's a Geometry that defines the shape and, second, there's a Path that utilizes them and adds i.e. the colors, etc.; for instance, for the left arrow this looks like the following:

<Geometry x:Key="ArrowLeft">M0,5 L10,10 10,0Z</Geometry>
<Path x:Key="ArrowLeftPath"
      Margin="4,3"
      Data="{StaticResource ArrowLeft}"
      Stroke="{StaticResource LineButtonBrush}" 
      Fill="{StaticResource LineButtonBrush}"
      Stretch="Fill"
      VerticalAlignment="Center"
      HorizontalAlignment="Center"/>

If you're not familiar with Geometries and the "geometry mini language", I suggest to bing or google that - it's so much more convenient compared to the long version of their more verbuous counterparts, especially if only a small count of points is required, in which case you can really learn to read them over time.

Regarding the converters: While, in the beginning, I really wanted a XAML-only solution, this was no longer possible since I really really wanted the scroll buttons to be disabled when scrolling isn't possible, i.e., when the viewport is either on the far left or far right. The far left isn't much of a problem - we could simply compare the HorizontalOffset property to zero, in which case scrolling to the left wouldn't be possible. However, in order to find out whether the Viewport is on the far right, we have to compare the Extent's width against the sum of the Viewport's width plus the HorizontalOffset, IOW, scrolling to the right not possible if [HorizontalOffset + Viewport.Width] = Extent.Width. Sadly, this is not possible without a converter due to the necessity of a MultiBinding, hence this part will require some code. However, we're not talking about the need for code-behind for every TabControl we use, but rather about a loosely coupled class. The TabControl's style can thus still be used throughout your project as long as the Converter is part of that project, too. A drawback for sure, but a minor one, if you ask me. Since we need one converter for the right-button, I thought it'd make sense to also provide one for the left-button.

You'll find both converters in the ScrollBarConverters.cs file (resp. ScrollBarConverters.vb).

Ready to (sc)roll ..?

If you downloaded the sample solution (see the bottom for the link), click the 3. ScrollViewer with Scroll-Buttons button to show the window with the result of the above. You'll get something this (click for a larger image):

That's better - we can now scroll the TabPanel in order to get at the TabItems that are invisible/inaccessible. Let's add some functionality that I personally learned to value.

 

The TabControl in SAP's WebGUI

Actually, the functionality I wanted is is more or less equal to that of the TabControl in SAP's WebGUI. In early 2008 SAP tasked us to build a WinForms companion to SAP's WebGUI, that is, to implement a WinForms counterpart for the controls contained in their library. This set of WinForms controls was then used for implementing an offline client for SAP's cProjects (which is a part of SAP PS). Here's a sample screenshot of our test-client (click to enlarge):

In the above screenshot, you can see the bottom-most TabControl "in action", featuring three buttons on the right extent of the TabPanel - one for each scrolling to the left and right and another one. Another one? Yup, this one opens up a popup-menu in which all TabItem's headers are listed, allowing users to quickly select an item from the list, activating the selected TabItem, even if it's out of view when selected. (This TabControl was one of the most complicated and non-amusing controls I've ever had to build; if you ever need to build your own TabControl with WinForms, tell ya - it's not what I consider "fun". With WPF OTOH, this is just so much easier, less complicated, way more flexible, faster, fun, ... you name it!)

So, what do we have to do in order to create such a menu? Again, we can settle with a no-code / XAML-only solution!

 

Enter the Menu and MenuItem controls

First thing you probably thought of was ... the ContextMenu? Well, I did. But instead of convincing a ContextMenu to popup, I resembled to applying a custom style to the Menu and the MenuItem controls. First, let's have a look at the XAML that we'll need to add to the StackPanel (which already contains the scroll buttons) in order to get the menu in the right place:

<Menu Background="Transparent">
   <MenuItem Style="{StaticResource TabMenuButtonStyle}"
             ItemsSource="{Binding RelativeSource=
               {RelativeSource FindAncestor, 
                  AncestorType={x:Type TabControl}}, 
                  Path=Items}"
             ItemContainerStyle="{StaticResource TabMenuItem}">
   </MenuItem>
</Menu>

Pretty short really, right? Of course, the style for the control isn't part of the XAML, but assuming that, in a real world solution, the style will rather be dropped into a separate ResourceDictionary, this is all you need in your TabControl's style (no no, I wouldn't call that cheating!). Thus, the only really interesting part about the XAML above really is the binding that is applied to make the menu (well, the MenuItem, really) show all TabItems' Header texts. But it's probably easier than you might have thought, because all we have to do is to point the MenuItem to the TabControl and then bind to its TabItems. I love it - with WinForms that was so much more code!

I won't fancy discussing the style for the MenuItem in depth here. If you inspect the XAML in the sample solution, you'll find it documented - just look for TargetType="{x:Type MenuItem}" to find the two styles (one for the MenuItem that makes up for the Button in the StackPanel and one for the popup menu with the items themselves). Two side notes here: First, I actually failed to provide a hover-effect for disabled TabItems, the reason being the fact that disabled items will never receive any HitTest information. As a result, you won't see any indication when you hover over disabled items found in the menu; oh well. Second, I thought that it'd be fun to again use the geometry mini language in order to create the button's image which should be pretty close to SAP's original icon, only that this one's scalable.

Here's a screenshot of what we have now (click for a larger image):

(If you downloaded the sample solution (see the bottom for the link), click the "4. TabItem-menu added" button to show the window above.)

 

Are we done yet?

At this point, you might want to sit back and determine whether the above already gives you what you need for your own TabControl. There's really only a couple of things that are worth dealing with the rest of the article - one minor and two major things:

1. Selecting a TabItem from the menu will not bring the first and last TabItems into view completely (major)
2. Clicking the scroll buttons will scroll by whole pages (major)
3. The TabItems on the left and right of the ScrollViewer's Viewport will be cut off abruptly (minor)

Why am I saying this? The first item might not apply to you - if you don't use negative margins, this would fade away silently. The second and third items might not be important to you. To me, however, all of these three are inacceptable. So ...

 

Enter IScrollInfo

Dealing with the aforementioned drawbacks turned out to be impossible by means of XAML only (I tried real hard!). So I opted to create my own panel instead. The "wanted" features that made it onto my list:

• more control over the scrolling position when moving to the beginning resp. end of the Viewport (allowing negative margins of contained controls at the edges of the Extent)
• more control over the offset that's being applied during scrolling
• animated scrolling
• a "fading" effect for TabItems that are only partially visible
• get rid of the converters required for binding the scroll buttons' IsEnabled property

To create your own panel, you can simply inherit from Panel. However, to provide your own scrolling logic, we'll need to implement IScrollInfo.
IScrollInfo really is a beast! If you have VisualStudio create the methods required for implementing this interface for you, you'll be left with as much as 9 properties and 15 methods! Here's the list (in the order that VS creates them):

   public bool CanHorizontallyScroll
   public bool CanVerticallyScroll
   public double ExtentHeight
   public double ExtentWidth
   public double HorizontalOffset
   public void LineDown()
   public void LineLeft()
   public void LineRight()
   public void LineUp()
   public Rect MakeVisible(Visual visual, Rect rectangle)
   public void MouseWheelDown()
   public void MouseWheelLeft()
   public void MouseWheelRight()
   public void MouseWheelUp()
   public void PageDown()
   public void PageLeft()
   public void PageRight()
   public void PageUp()
   public ScrollViewer ScrollOwner
   public void SetHorizontalOffset(double offset)
   public void SetVerticalOffset(double offset)
   public double VerticalOffset
   public double ViewportHeight
   public double ViewportWidth

Most of the above methods are either pretty easy to implement (such as LineLeft/LineRight) or do not need to be covered (LineDown/Up, PageDown/Up, MouseWheel*) at all. However, the MakeVisible method needs some more intense care-taking, as does the SetHorizontalOffset method.

BTW - note that the sample class will simply skip anything related to mouse wheel actions and any actions targetting the vertical axis. If you plan to use the TabControl with its TabItems drawn on the left or right, you'll have to add these accordingly for the latter; in this case however, you'll have to reconsider a whole bunch of other things anyway ...

Back to IScrollInfo. Besides the fact that we have to implement the methods and properties of the IScrollInfo interface, we also need to override a couple of methods, the most important being MeasureOverride and ArrangeOverride. I won't discuss the whole class here as that could a) get quite boring (with respect to this article being geared at the TabControl) and b), considering that there's a substantial amount of code involved. FWIW - you'll find the code well documented in the sample solution and if you encounter any problems or want to know more about any specifics, leave a comment.

A couple of things can not be set aside though. For instance, the two aforementioned methods deserve some explanation which is critical for understanding the concept behind this, so here goes.

 

IScrollInfo: MeasureOverride and ArrangeOverride

When elements are being added to (or removed from) your control or one of the elements is re-rendered (i.e. after its size has changed), the whole layout of the control (that is, the Extent and Viewport) needs to be rearranged. This requires a two-fold process to which the .Net framework refers to as the two pass layout updating process. This means that, whenever the layout needs to be updated, the compiler will call both methods. In MeasureOverride we need to determine the overall size of the control (i.e., the Extent) that is required to host all contained elements; in the sample class, only the width is relevant, so the class will iterate over all elements, sum up their desired width and return the result; the height will remain constant at all times.

Once that is done, the elements need to be arranged within the Extent, hence the second pass - ArrangeOverride. Here, we again iterate over all children and define the (horizontal) position for each of them. In some situations, the arranging of the children may result in the need to perform both first and second pass again, so this sequence may be called several times. For the ScrollableTabPanel (being the sample class) however, this is not the case.

Again, IScrollInfo would really deserve (require!) its own article, hence I'll skip everything else related to this interface at this point. A little hint though: if you want to know more about those two methods, I suggest you check the MSDN docs on UIElement.Measure and UIElement.Arrange - while you'll find control-specific topics in the docs about MeasureOverride and ArrangeOverride, the detail covered there doesn't compare to what you'll find in the respective ones behind the aforementioned links! Also, there should be plenty of tutorials on IScrollInfo basics throughout the web.

 

Animating the Panel

One of the two other things that I think are worth mentioning is the fact that, whenever the ScrollableTabPanel scrolls, the process will be animated (as opposed to instantly switching to the final position). Two simple reasons for that - when the user scrolls the panel, there is no real visual indication of what happens; by animating the process the user has (IMHO) a far better chance to see what's going on behind the scenes. Second, the animation is stupidly easy to implement - it's basically not more than a single line of code. In the solution's class, you'll actually see a couple of lines, but that's rather because I wanted the animation to a) accelerate and decelerate and b) because an update of the TabItems is required - after the animation has ended (the OpacityMasks need to be updated - more on that below).

 

Having the TabItems at the edges of the Viewport fade into nothingness

Last but not least, I wanted to give the user a visual indication in the case a TabItem (strip) was only partially visible, indicating that there is more items to the left or right. Achieving that was way trickier than I originally thought really (but hey, we all like digging into stuff like that, don't we ...). When I was thinking about the fade-effect, I thought of applying an Opacity Mask right away. My first attempt (call me dumb) was to apply a mask to the left and right edge of the ScrollViewer (that was actually before I implemented the ScrollableTabPanel), which is as simple as creating a (horizontal) LinearGradientBrush that fades into Colors.Transparent at its edges and then applying the resulting Brush to the OpacityMask property of whatever control in question. (BTW - it doesn't matter at all what other color(s) you place into such a brush - for an OpacityMask, only the alpha channel is important, thus the color itself (meaning the R, G and B channels) is irrelevant.) This way, only those portions (colors) of the control/content itself with an alpha-value >0 will be affected by the "fader brush".

Well, it of course wasn't that easy - the OpacityMask will be applied to the Extent of the control, rather than the Viewport - I hence did not succeed in defining an Opacity mask that would stick to the Viewport's bounds; if you know a way, make sure you leave a comment!
I thus opted to apply the mask to the TabItems themselves. In this case though, the whole task gets a little more complicated because the brush itself needs to consider the width of each TabItem, if the fade effect is to remain as constant as possible (which is not all too much, depending on how narrow the visible portion gets, but you'll see that yourself). In the ScrollableTabPanel class, you'll see that I simply calculate exactly how much of each TabItem is visible (i.e. ranging from 0 = completely invisible to 1 = completely visible). The factor or ratio gained will then be applied to the StartPoint or EndPoint respectively.
A minor quirk with this is the fact that all OpacityMasks need to be removed prior to performing scrolling as, otherwise, the faded edges would remain visible until the Viewport has reached its final position. But oh well, you can't have it all, can you.

 

But wait!

One last thing before we go and have a beer or two: If you used the keyboard to tab through the controls in the previous versions, you may have noticed that the focus indicator (aka the dashed border) was either not looking OK or even off limits at times. In the last window of the sample solution, I have therefore added another style for that (look for the key "TabItemFocusVisual"). This, again, imposes another minor issue: this can't be dealt with by means of an adorner (Dr. WPF has recently published a nice article on this), so I had to stick with calling InvalidateArrange() instead. However, this again can be called (reliably) only after any scrolling has taken place resp. finished. You will thus see the dashed border "move" when you loop through the TabItems with the keyboard (to do so, focus the slider and then hit the left/right arrow keys). However, IMNSHO the effect is too minor to deserve some decent appreciation (especially if you don't zoom in), so I'll leave that as it is now and rather go and have my beer.

 

The last word

This concludes Part Three of the TabControl series. It shouldn't really take too long to assemble the last part (the last part currently planned, that is ) as I've dealt with the close-button (and images) in another solution already. Maybe next week - we'll see. As for me, I sure learned a bunch of new things and details about the ScrollViewer and IScrollInfo - I hope you enjoyed it a bit, too.

As always, I'd appreciate you leaving a comment - whether you liked it or not, or in case you need further clarification on any of the topics discussed here - I'll do my very best to answer them.

 

The sample solution

I’ve created a sample solution that contains everything discussed here. Other than with the previous parts, the solution now again contains one project for each the C# and the VB versions.

Download: TabControlStyle - Part Three.zip (105.68 kb)

Location: PostList

Introduction

In my previous article, I started the TabControl series, demonstrating how to define a new Style for the TabControl, its TabItemPanel and the TabItems. Today I will extend the sample introduced there, adding transition effects that are being applied to the TabItems when they change state (for instance, from Selected to Unselected).

 

Overview

This article is part of a multi-part series. Here's the four parts of the series:

• WPF: TabControl Series - Part 1: Colors and Sizes
• WPF: TabControl Series - Part 2: Animating the TabItems (this article)
• WPF: TabControl Series - Part 3: Non-wrapping scrollable TabPanel; TabItem DropDown-Menu
• WPF: TabControl Series - Part 4: Closeable TabItems

 

Outcome: the result of what's covered in this article

Here's what we'll be left with at the end of this article:

 

Status quo (after Part One)

As noted before, this article is based upon the stuff I introduced in Part One. If you haven't read it and find that you need to find out more about the basics, I suggest that you start there.
Here's where we'll start here, i.e. what the TabControl and its "sub-controls" looked like at the end of Part One:

 

Animating ... what?

Basically, the above style IMHO makes up for a much better appearance compared to the original template. However, when the user hovers over a TabItem or selects a different TabItem, the change will be instant. The goal of this article is to change that so that there's more of a smooth transition between states.

Let's do a quick recap on the different states that a TabItem can take: 

1. Unselected (i.e., the default)
2. Selected
3. Disabled
4. Hover (i.e., the mouse is over the TabItem)

I'll leave out the Disabled state with respect to animations as I presume that, for most of all times, that state will have been determined to be required before the control is actually being shown, hence animating it shouldn't be required. If you do want to add a transition effect for that as well, it should be pretty easy once the concept has become clear.

Let's start with what state-changes we would need to support. These are:

• Unselected » Selected
• Unselected » Hover
• Selected » Unselected
• Hover » Unselected
• Hover » Selected

So, where's the Selected » Hover state change? I'm simply not considering it due to the fact that I don't want any effect when the mouse hovers over the selected TabItem. As a matter of fact, the style introduced in Part One doesn't consider this either.

 

States of the TabItems

Back when I created Part One's style I thought that adding some animations to the TabItem would be a matter of a couple of minutes. However, as it turned out, the whole thing got me pretty much stuck for quite a while. To be precise, I spent an absolutely ridiculous amount of time trying to find out why it wouldn't work as desired. Up until now I still think that there's a bug somewhere in the part of the framework that's responsible for the animations resp. Storyboards. But let's start with the fundamentals first. In order to provide the transition between TabItem-states, we first need to determine what type of animation is the most suitable for what we're planning to achieve. In Part One, I introduced a couple of Thickness resources that were targetting the TabItems' Margin property. These were defined as follows:

<Thickness x:Key="TabItemMargin_Base">0,8,-4,0</Thickness>
<Thickness x:Key="TabItemMargin_Selected">-4,0,-4,0</Thickness>
<Thickness x:Key="TabItemMargin_Hover">0,2,0,0</Thickness>
<Thickness x:Key="TabItemPanel_Padding">4,0,0,0</Thickness>

The last one (TabItemPanel_Padding) isn't of any interest with respect to animations (see the comments in the XAML of the sample solution) - it's only part of the group in order to rather have all the Margin assignments in a central place (allowing for easier changing them when required). The resources' names should be pretty self-explanatory for all but the first: TabItemMargin_Base actually refers to what I would call the default state of TabItems - the Unselected state. That being said, whenever a TabItem changes into that state, its size will be determined by the available height minus the 8px top-margin (making it a little smaller in height). Also, adding -4px as the right margin will effectively apply a negative amount, allowing the TabItem to the right (of the one to which this is being applied) to overlay it, which in turn "removes" (covers) the rounded corner on the TabItem's top right, resulting in the overlay-effect (can I call that 2.9D?). The TabItemMargin_Hover resource will make two changes compared to TabItemMargin_Base: the height-reduction is two pixels less, which will render the hovered TabItem 2px higher in comparison. Also, the negative right margin is removed which results in the hovered TabItem no longer being covered by the TabItem to the right (if there is one anyway). Finally, the TabItemMargin_Selected resource further increases the height resp. allows the TabItem to extend to the full height that the TabItemPanel allows for; since this is also the state at which TabItems are to receive the user's strongest attention, negative left and right margins are being applied so that the selected TabItem will always cover the TabItems to the left and right respectively. What you can't see in the XAML above is the fact that the ZIndex property is part of the gameplay here, too. That is, the ZIndex is changed with respect to the TabItem's state - from back to front:

1. Disabled (lowest)
2. Unselected
3. Hover
4. Selected (highest)

 

ThicknessAnimation

With the above Margin-settings we actually have all we need to apply state-transitions resp. create/define our animations. The framework provides a wealth of animation-types; that being said, there is more than one way to create the transitions. However, there also is the ThicknessAnimation which is just what we need, since we really want to animate the TabItems' Margin-property, and the Margin actually is a ... Thickness! Also, utilizing a ThicknessAnimation allows us to simply neglect any starting parameters or values. Instead, we can define all we need only by defining the Margin as it is to be applied when the animation ends - the ThicknessAnimation will thus run from whatever source Margin it uses to the value we specify (there is other combinations such as using From or By or a combination of them - see the MSDN docs for more information). To a) keep things in a central place and b) allow for not having to define something more than once, we'll again make use of resources instead. Here's a sample of the Storyboard-resource that is to run when a TabItem enters the Selected state:

<Storyboard x:Key="TabItemStoryBoard_Selected">
   <ThicknessAnimation Storyboard.TargetName="Border" 
                             Storyboard.TargetProperty="Margin"
                             To="{StaticResource TabItemMargin_Selected}" 
                             FillBehavior="HoldEnd"
                             Duration="0:0:0.1"/>
</Storyboard>

A couple of points deserve attention in the above XAML: We want to apply the animation to the Margin-property of the TabItem, hence the TargetProperty-assignment. The TargetName property is set to Border simply because that's the name of the the Border-control that we defined in the TabItem's Template and which is the parent-control of its ContentPresenter (see Part One for more info). By setting the FillBehavior property to HoldEnd, we determine that the animation is to not bother with resetting the Margin back to its original value but rather to leave it where it is, once the animation ends. (Actually, HoldEnd really is the default value, but in cases like this I tend to be explicit since it adds to the code's overall readability.)
Finally, since we defined a Margin-resource that is to be reached by the time the animation ends, we'll simply pass its name to the To property, making up for the state that we'd like to have reached when the animation ends.

The above principle can actually be applied to all other animations in the exact same way, only replacing the Margin-resource in the To-property with the respective resource's name.

 

A (better) alternative?

However, I'd like to introduce another type of animation that allows us to perform the same task with an alternative approach - the ThicknessAnimationUsingKeyFrames. If we wanted to instead use the ThicknessAnimationUsingKeyFrames to achieve the same effect as in the prior XAML, the equivalent would look like this:

<Storyboard x:Key="TabItemStoryBoard_Selected">
   <ThicknessAnimationUsingKeyFrames Storyboard.TargetName="Border" 
                                           Storyboard.TargetProperty="Margin"
                                           FillBehavior="HoldEnd">
      <SplineThicknessKeyFrame KeyTime="0:0:0.1"
                                     Value="{StaticResource TabItemMargin_Selected}"/>
   </ThicknessAnimationUsingKeyFrames>
</Storyboard>

A little bit more complex compared to the ThicknessAnimation, huh, so why the hell bother with it? The reason is that the ThicknessAnimationUsingKeyFrames gives us a chance to define several states resp. changes during the scope of a single Storyboard/animation. To better illustrate this (ah well, maybe that's more about finding a valid reason), I thought it'd be fun to utilize this type of animation when animating the change of height that is to be applied when a TabItem enters the Hover state. That is, instead of just having the TabItem extend the height by 4px (well, actually we only reduce the reduction, luv'it ) when the mouse hovers over it, we'll apply two KeyFrames, the first with a 2px and the second with the final value of a 4px reduction. As a result, the TabItem will first extend above its final height and then swing back to the final value (being 4px). Since we have defined the target margins as resources, we'll simply split up the original TabItemMargin resource into two new ones, dumping the original one:

<!--<Thickness x:Key="TabItemMargin_Hover">0,4,-4,0</Thickness>-->
<Thickness x:Key="TabItemMargin_Hover_Start">0,2,0,0</Thickness>
<Thickness x:Key="TabItemMargin_Hover_Final">0,4,0,0</Thickness>

Note: If you fell for the right Margin of -4 having been replaced by 0 - don't bother, we'll get to that later on.

Now the ThicknessAnimationUsingKeyFrames comes back into play, which is where all we have to do is to provide the two KeyFrames that will utilize the above two resources:

<Storyboard x:Key="TabItemStoryBoard_Hover">
   <ThicknessAnimationUsingKeyFrames Storyboard.TargetName="Border" 
                                           Storyboard.TargetProperty="Margin"
                                           FillBehavior="HoldEnd">
      <SplineThicknessKeyFrame KeyTime="0:0:0.1"
                                     Value="{StaticResource TabItemMargin_Hover_Start}"/>
      <SplineThicknessKeyFrame KeyTime="0:0:0.2"
                                     Value="{StaticResource TabItemMargin_Hover_Final}"/>
   </ThicknessAnimationUsingKeyFrames>
</Storyboard>

Et voilà - that's all we have to do. And, by the way, both the ThicknessAnimation and the ThicknessAnimationUsingKeyFrames are not restricted to a single dimension such as either height, width, left, top, etc., but to the Thickness definition itself. That is, this would work just as well if we wanted a transition between a Margin of 10,5,0,2 and 5,0,2,10.

 

At a glance: the Storyboards

Here's all three Storyboards that we need:

<!-- This will run when a TabItem enters the "Unselected" state -->
<Storyboard x:Key="TabItemStoryBoard_Unselected">
   <ThicknessAnimation Storyboard.TargetName="Border" 
                             Storyboard.TargetProperty="Margin"
                             To="{StaticResource TabItemMargin_Base}"
                             FillBehavior="HoldEnd"
                             Duration="0:0:0.1"/>
</Storyboard>
<!-- This will run when a TabItem enters the "Selected" state -->
<Storyboard x:Key="TabItemStoryBoard_Selected">
   <ThicknessAnimation Storyboard.TargetName="Border" 
                             Storyboard.TargetProperty="Margin"
                             To="{StaticResource TabItemMargin_Selected}" 
                             FillBehavior="HoldEnd"
                             Duration="0:0:0.1"/>
</Storyboard>
<!-- This will run when a TabItem enters the "Hover" state -->
<Storyboard x:Key="TabItemStoryBoard_Hover">
   <ThicknessAnimationUsingKeyFrames Storyboard.TargetName="Border" 
                                           Storyboard.TargetProperty="Margin"
                                           FillBehavior="HoldEnd">
      <SplineThicknessKeyFrame KeyTime="0:0:0.1"
                                     Value="{StaticResource TabItemMargin_Hover_Start}"/>
      <SplineThicknessKeyFrame KeyTime="0:0:0.2"
                                     Value="{StaticResource TabItemMargin_Hover_Final}"/>
   </ThicknessAnimationUsingKeyFrames>
</Storyboard>

Alright, now all we have to do is to go ahead and apply the Storyboards we just defined. Since the Triggers that come into play for state-changes are already in place, that would (should) mean that this would be a matter of adding EnterActions for the three Triggers we already have in our XAML.

 

Ain't that easy after all, it seems ...

However, this is where what I thought to be overly simply became more like a nightmare. Since this is a rather long story, you can read this thread on the MSDN WPF forums (German!) for the very long story or to this thread (in English) for the long story. I have posted a simplified and ready-to-run sample in both threads which illustrates the issues I was encountering. Since I don't want to rap so much about what doesn't work but rather demonstrate what does, let's just cut this short - here's what I really had to do and what you might stumble over in the XAML ahead:

1. While the documentation states that the default RepeatBehavior of a Storyboard means that the animation will only run once, there seems to be a bug of some sort that forced me to manually stop them at certain occasions.
2. The above in turn leads to the necessity of naming the Storyboards when they are started from the Triggers. Since the names have to be unique, I suffixed them with an indication of the respective Trigger it was created in.
3. There seems to be some sort of interference that must be happening due to the fact that the Storyboard that runs when a TabItem enters the Unselected state is being used multiple times (i.e. Hover » Unselected and Selected » Unselected). This forced me to replace the Unselected Trigger to a MultiTrigger (analogous to the Hover-MultiTrigger). 

Ah well ...

 

At a glance: the Triggers with the Storyboards applied

... here's the complete XAML section in which all Triggers are defined and which is where the Storyboards are put into action:

<ControlTemplate.Triggers>
   <!-- The appearance of a TabItem when it's inactive/unselected -->
   <MultiTrigger>
      <MultiTrigger.Conditions>
         <Condition Property="Border.IsMouseOver" Value="False"/>
         <Condition Property="IsSelected" Value="False"/>
      </MultiTrigger.Conditions>
      <!-- The Triggers required to animate the TabItem when it enters/leaves the "Unselected" state (added in part two) -->
      <MultiTrigger.EnterActions>
         <BeginStoryboard x:Name="sbUnselected"
                                            Storyboard="{StaticResource TabItemStoryBoard_Unselected}"/>
      </MultiTrigger.EnterActions>
      <MultiTrigger.ExitActions>
         <StopStoryboard BeginStoryboardName="sbUnselected"/>
      </MultiTrigger.ExitActions>
      <Setter Property="Panel.ZIndex" Value="90" />
      <Setter TargetName="Border" Property="Background" 
                                Value="{StaticResource TabItem_BackgroundBrush_Unselected}" />
      <Setter TargetName="Border" Property="BorderBrush" 
                                Value="{StaticResource TabItem_Border_Unselected}" />
      <Setter Property="Foreground" 
                                Value="{StaticResource TabItem_TextBrush_Unselected}" />
      <!-- Except for the selected TabItem, tabs are to appear smaller in height. -->
      <Setter TargetName="Border" Property="Margin" 
                                Value="{StaticResource TabItemMargin_Base}"/>
   </MultiTrigger>

   <!-- 
                        The appearance of a TabItem when it's disabled 
                        (in addition to Selected=False)
                     -->
   <Trigger Property="IsEnabled" Value="False">
      <Setter Property="Panel.ZIndex" Value="80" />
      <Setter TargetName="Border" Property="BorderBrush"
                                Value="{StaticResource TabItem_DisabledBorderBrush}" />
      <Setter TargetName="Border" Property="Background" 
                                Value="{StaticResource TabItem_BackgroundBrush_Disabled}" />
      <Setter Property="Foreground" 
                                Value="{StaticResource TabItem_TextBrush_Disabled}" />
      <Setter TargetName="Border" Property="Margin" 
                                Value="{StaticResource TabItemMargin_Base}"/>
   </Trigger>

   <!-- The appearance of a TabItem when the mouse hovers over it -->
   <MultiTrigger>
      <MultiTrigger.Conditions>
         <Condition Property="Border.IsMouseOver" Value="True"/>
         <Condition Property="IsSelected" Value="False"/>
      </MultiTrigger.Conditions>
      <!-- The Triggers required to animate the TabItem when it enters/leaves the "Hover" state (added in part two) -->
      <MultiTrigger.EnterActions>
         <StopStoryboard BeginStoryboardName="sbUnselected_Hover_Exit"/>
         <BeginStoryboard x:Name="sbHover"
                                            Storyboard="{StaticResource TabItemStoryBoard_Hover}"/>
      </MultiTrigger.EnterActions>
      <MultiTrigger.ExitActions>
         <BeginStoryboard x:Name="sbUnselected_Hover_Exit" Storyboard="{StaticResource TabItemStoryBoard_Unselected}"/>
      </MultiTrigger.ExitActions>
      <Setter Property="Panel.ZIndex" Value="99" />
      <Setter Property="Foreground" Value="{StaticResource TabItem_TextBrush_Hover}" />
      <Setter Property="BorderBrush" 
                                TargetName="Border" 
                                Value="{StaticResource TabItem_HoverBorderBrush}" />
      <Setter TargetName="Border" Property="BorderThickness" Value="2,1,1,1" />
      <Setter Property="Background" TargetName="Border"
                                Value="{StaticResource TabItem_HoverBackgroundBrush}"/>
      <!-- 
                           To further increase the hover-effect, extend the TabItem's height a little
                           more compared to unselected TabItems.
                        -->
      <Setter TargetName="Border" Property="Margin" 
                                Value="{StaticResource TabItemMargin_Hover_Final}"/>
      <!--
                           At runtime, we want a transition when changing between the regular/hover/regular
                           states.
                        -->
   </MultiTrigger>

   <!-- The appearance of a TabItem when it's active/selected -->
   <Trigger Property="IsSelected" Value="True">
      <!-- The Triggers required to animate the TabItem when it enters/leaves the "Selected" state (added in part two) -->
      <Trigger.EnterActions>
         <StopStoryboard BeginStoryboardName="sbUnselected_Selected_Exit"/>
         <BeginStoryboard x:Name="sbSelected"
                                            Storyboard="{StaticResource TabItemStoryBoard_Selected}"/>
      </Trigger.EnterActions>
      <Trigger.ExitActions>
         <BeginStoryboard x:Name="sbUnselected_Selected_Exit" Storyboard="{StaticResource TabItemStoryBoard_Unselected}"/>
      </Trigger.ExitActions>
      <!-- We want the selected TabItem to always be on top. -->
      <Setter Property="Panel.ZIndex" Value="100" />
      <Setter TargetName="Border" Property="BorderBrush" 
                                Value="{StaticResource TabItem_BorderBrush_Selected}" />
      <Setter TargetName="Border" Property="Background" 
                                Value="{StaticResource TabItem_BackgroundBrush_Selected}" />
      <Setter TargetName="Border" Property="BorderThickness" Value="1,1,1,0" />
      <Setter Property="Foreground" 
                                Value="{StaticResource TabItem_TextBrush_Selected}"/>
      <Setter TargetName="Border" Property="Margin" 
                                Value="{StaticResource TabItemMargin_Selected}"/>
   </Trigger>
</ControlTemplate.Triggers>

 

But wait!

If you stumbled over the fact that I got rid of the right Margin of 4px for the hover-effect when I replaced the TabItemMargin_Hover_Start Margin resource with the split up ones - here's the reason. If you run the sample solution, comparing the two Windows it comes with (one for what we started with and one for what we have now), you'll notice that, for the non-animated sample, the hover-effect will include the hovered TabItem to come up to the front. The reason is simple - each state-Trigger comes with its own ZIndex-setting; the Hover-Trigger's ZIndex places it only behind the selected TabItem, but in front of all others. Now, by removing the right Margin in the animated TabItem's Style, we actually animate the width of the item along the way, resulting in the hovered TabItem seeming to "push" any other TabItem to its right out of the way. Hey, I like that. We could as well have defined the right margin of the TabItemMargin_Hover_Start resource (i.e., the first of the animation's two frames) to be 1px which would've smoothed the effect a little more, but I'll leave that up to you.

 

The last word

This concludes Part Two of the TabControl series. As always, I'm very happy to receive any kind of feedback for the stuff I'm publishing.

 

The sample solution

I’ve created a sample solution that contains everything discussed here. As with Part One, the solution is C# only, but there is no code behind involved whatsoever (not taking the main form into account) which is why you won't find a VB counterpart. However, if you want to use this in a VB-project, simply paste the XAML into your VB-window and remove the TabControlStyle. that is preluding each window's x:Class attribute (and indicating the namespace that is required for C#).

Download: TabControlStyle - Part Two.zip (23.29 kb)

Location: PostList