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

I'm pretty busy at present, hence I haven't had much time to write new blog entries. However, today I came about a thread in the WPF forum where the OP asks for a way to concatenate multiple fields for a binding. Now, since I (IIRC) have written about this several times in the forums (I guess everybody at one time will stumble over that - I did) and this is actually something that sure qualifies for a less-than-30-minutes-blog-entry (edit: ... or so I thought; I recently updated to BlogEngine 1.6 and the code-formatter was giving me one hell of a hard time!), I thought I'd write another quickie, so here's what I'm using as a sort of generic approach for stuff like this.

Note that, even though I only present C# code in this article, the sample solution (see the bottom for the download) contains both a project for C# and VB.

 

Edit (April 21st 2010)

Please note that I had to find out that the Converter I'm introducing here isn't even required to do the job outlined in this article. See the last paragraph (But wait!) for more information.
I'm leaving the blog-post here anyway (might as well help to teach somebody else the same lesson ). And, as of April 30th 2010, I'm again turning around 180°, stating that the Converter is useful (again, see the bottom of this post).

 

The problem

The class that provides the data for your window has i.e two fields that are to be shown in a single column of a ListBox (or ListView, GridView, you name it). The classical fields are the LastName/FirstName combos.

 

The sample data

For the remainder of the blog, I've created a simplistic class Person, that will only provide the two properties LastName and FirstName. Here it is:

   public class Person
   {
      private string _LastName;
      public string LastName
      {
         get { return _LastName; }
         set { _LastName = value; }
      }

      private string _FirstName;
      public string FirstName
      {
         get { return _FirstName; }
         set { _FirstName = value; }
      }

      public Person(string LastName, string FirstName)
      {
         this.LastName = LastName;
         this.FirstName = FirstName;
      }
   }

 

 

Possible approaches

There's basically three approaches to working out a solution:

1. Addding another property to the class that provides the data; for our Person class, this could be a LastFirstName prop, returning this.LastName + " " + this.FirstName
2. If you're using a database (with or without ORM), either have the SELECT return the concatenated field or, if your DB is capable of it, add a computed column (i.e. as feasible with SQL Server for ages)
3. Adding a converter that concatenates the fields

So, what approach would win a prize for simplest, best, nicest? It depends, of course.
FWIW, I tend to find generic approaches whereever possible. That having been said, I dislike the another property in my data-class approach - simply because I'll have to provide such a property for every class where I need to concatenate fields. The DB-based approach is not even close to practical either - what if I don't have control over the database (this has happened quite a few times).

Alright, the title of the article suggested it - I'll show you how to create a pretty simple converter to do the trick. But why? The converter is a stand-alone class that I can drop into any project and, from there on, use it with whatever fields I need to concatenate. It also allows me to concatenate a bunch of fields (as opposed to only two of them - think of a delimited list).

 

Enter the IMultiValueConverter interface

I was just about to paste a link to the IMultiValueConverter Interface docs on MSDN, so I looked it up and flew over it. Duh - the article contains quite a few bits that I was to describe here! Besides some error-handling (which of course should be in place!), there's really two tiny bits my converter has that the MSDN samples don't - a) I'm utilizing the parameter argument, allowing to specify the delimiter to be used when concatenating and b) my converter doesn't restrict you to just two fields. Here's the converter's code (note that I stripped off all the comments and the sample XAML - you'll find that in the sample solution (see the bottom of this post for the download-link).

   [ValueConversion(typeof(object), typeof(string))]
   public class ConcatenateFieldsMultiValueConverter : IMultiValueConverter
   {
      public object Convert(
                  object[] values, 
                  Type targetType, 
                  object parameter, 
                  System.Globalization.CultureInfo culture
               )
      {
         string strDelimiter;
         StringBuilder sb = new StringBuilder();

         if (parameter != null)
         {
            //Use the passed delimiter.
            strDelimiter = parameter.ToString();
         }
         else
         {
            //Use the default delimiter.
            strDelimiter = ", ";
         }

         //Concatenate all fields
         foreach (object value in values)
         {
            if (value != null && value.ToString().Trim().Length > 0)
            {
               if (sb.Length > 0) sb.Append(strDelimiter);
               sb.Append(value.ToString());
            }
         }

         return sb.ToString();
      }

      public object[] ConvertBack(
                  object value, 
                  Type[] targetTypes, 
                  object parameter, 
                  System.Globalization.CultureInfo culture
            )
      {
         throw new NotImplementedException("ConcatenateFieldsMultiValueConverter cannot convert back (bug)!");
      }

   }

 

Using the converter with your XAML

Let's see how to actually make use of the converter in XAML. First of all, since we reference a class within the project from XAML, we need to add the underlying namespace to the window:

<Window x:Class="CS.DemoCS"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:CS"
        Title="DemoVB" Height="300" Width="300">
   (...)

From here on, we can now refer to classes in the project with the <local:[class]> syntax. The converter will furthermore need to be added as a resource. While this resource could be placed into the <[Control].Resources> section, I prefer to define my resources on the window-level, this way I only need to reference them once, so here goes:

   <Window.Resources>
      <local:ConcatenateFieldsMultiValueConverter x:Key="mvc"/>
   </Window.Resources>

From this point on, we can refer to the converter by its key mvc. Here's the complete XAML of the window you'll find in the sample solution:

<Window x:Class="CS.DemoCS"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:local="clr-namespace:CS"
        Title="DemoVB" Height="300" Width="300">
   <Window.Resources>
      <local:ConcatenateFieldsMultiValueConverter x:Key="mvc"/>
   </Window.Resources>
   <ListBox ItemsSource="{Binding PersonList}">
      <ListBox.ItemTemplate>
         <DataTemplate>
            <TextBlock>
               <TextBlock.Text>
                  <MultiBinding Converter="{StaticResource mvc}"
                                ConverterParameter=", ">
                     <Binding Path="LastName"/>
                     <Binding Path="FirstName"/>
                  </MultiBinding>
               </TextBlock.Text>
            </TextBlock>
         </DataTemplate>

      </ListBox.ItemTemplate>
   </ListBox>
</Window>

As you can see in the XAML above, the TextBlock I'm using as the ListBox'es DataTemplate uses a MultiBinding in order to pass the field-bindings as well as the delimiter to the converter which, in turn, will return the concatenated result.
If you wanted the ListBox to show its items as in "FirstName LastName", you'd only have to exchange the two bindings (having FirstName appear first) and change the ConverterParameter from ", " to " ".

For the sake of completeness, here's the code-behind of the window, so you can see the source of the bindings:

using System.Collections.Generic;
namespace CS
{
   public partial class DemoCS
   {

      //The source for the ListBox
      private List<Person> _lstPersons;
      public List<Person> PersonList
      {
         get { return _lstPersons; }
         set { _lstPersons = value; }
      }


      public DemoCS()
      {
         InitializeComponent();

         //Create the list of persons and add some entries for display
         _lstPersons = new List<Person>();

         _lstPersons.Add(new Person("Davolio", "Nancy"));
         _lstPersons.Add(new Person("Fuller", "Andrew"));
         _lstPersons.Add(new Person("Leverling", "Janet"));
         _lstPersons.Add(new Person("Peacock", "Margaret"));
         _lstPersons.Add(new Person("Buchanan", "Steven"));
         _lstPersons.Add(new Person("Suyama", "Michael"));
         _lstPersons.Add(new Person("King", "Robert"));
         _lstPersons.Add(new Person("Callahan", "Laura"));
         _lstPersons.Add(new Person("Dodsworth", "Anne"));

         this.DataContext = this;
      }

   }
}   

 

And here's the result of the sample window

The converter bonus

Another major advantage of the converter over any other alternative I can think of is the fact that, using a converter, we'll make use of the terrific data-binding possibilities WPF has to offer! That is, as a result, the converter's result can easily be used in scenarios where the fields that are being concatenated are changed by means of a different control on the same window. For instance, in my data-centric apps I often have windows in which I'm presenting a list of records, the selected item being the one loaded into detail-controls on the same window. Suppose we had a window with the ListBox control (containing list of Person-classes) on the left and one TextBox for each the LastName and FirstName property on the right - when the user selects an entry in the ListBox, the TextBoxes will allow to edit that entry. If you're using the converter, you'll see the data-binding magic kick in - changing i.e. the LastName in the TextBox would thus change it in the ListBox as well (provided INotifyPropertyChanged was properly implemented).

 

But wait!

Today (April 21st 2010), Richard posted a comment that was a real eye-opener. As it seems, the Converter actually isn't required at all. That is, utilizing the MultiBinding's StringFormat really makes the Converter obsolete:

<MultiBinding StringFormat="{}{0}, {1}">
   <Binding Path="LastName"/>
   <Binding Path="FirstName"/>
</MultiBinding>

Although I haven't tested this with lists that are being changed by other means, I'm pretty certain that the data-binding would work equally well for this. Another lesson learned!

Make sure you visit Lester's blog about the WPF 3.5 SP1 feature: StringFormat - wish I had come over that post earlier (again, thanks go out to Richard for mentioning this - see the comments).

Edit (April 30th 2010)

I came back to revisit this today, in an application I'm working on at present. I must admit I still feel stupid for not knowing about the StringFormat mentioned above. However, there actually still is the need for the Converter. That is, while the StringFormat does the job for the data presented in this post, it won't if your persons' names do not necessarily require users to enter a first name. In this case, the StringFormat will always print the comma (or whatever delimiter is being used) if you print your name-fields as in LastName, FirstName, even if there is no value for the FirstName field. That being said, I'm still favoring the Converter-approach (does that save my neck?).

 

The sample solution

If you still want to download the code, I’ve created a sample solution that contains everything discussed here with one project for each C# and VB.

Download: ConcatenateConverter.zip (26.30 kb)

Location: PostList