CompositionProToolkit v0.5.0 Holiday Edition released!

After a long gap, I am back with another update to CompositionProToolkit. This time I have added a few helper classes for the Win2d project.

CanvasPathBuilder extension methods

CanvasPathBuilder allows you to create a freeform path using lines, arcs, Quadratic Beziers and Cubic Beziers. You can then convert this path to a CanvasGeometry. Each path is composed of one or more figures. Each figure definition is encapsulated by the BeginFigure() and EndFigure() methods of CanvasPathBuilder.

If you want to add a circle(or ellipse) or a polygon figure to your path, you need to break the figure into curves or line segments and add them to the path one by one.

I have added the following extension methods to the CanvasPathBuilder to add a circle, ellipse or a polygon figure directly to your path

public static void AddCircleFigure (CanvasPathBuilder pathBuilder, Vector2 center, float radius);
public static void AddCircleFigure (CanvasPathBuilder pathBuilder, float x, float y, float radius);
public static void AddEllipseFigure(CanvasPathBuilder pathBuilder, Vector2 center, float radiusX, float radiusY);
public static void AddEllipseFigure(CanvasPathBuilder pathBuilder, float x, float y, float radiusX, float radiusY);
public static void AddPolygonFigure(CanvasPathBuilder pathBuilder, int numSides, Vector2 center, float radius);
public static void AddPolygonFigure(CanvasPathBuilder pathBuilder, int numSides, float x, float y, float radius);

In the AddPolygonFigure, the radius parameter indicates the distance between the center of the polygon and its vertices.

Note: These methods add the required curves or line segments to your path internally. Since these methods add a figure to your path, you can invoke them only after closing the current figure in the path. They must not be called in between BeginFigure() and EndFigure() calls, otherwise an ArgumentException will be raised. These extension methods call the BeginFigure() and EndFigure() CanvasPathBuilder methods internally.


Last month, while working on my new UWP app, I was using Win2d extensively and found out that in Win2d there was no support for the Path Mini Langugage which is quite popular in WPF/Silverlight. It is a powerful and complex mini-language which you can use to specify path geometries more compactly using Extensible Application Markup Language (XAML). It is derived mainly from the SVG (Scalable Vector Graphics) Path language specification. Here is an example


So I added the CanvasGeometryParser class which parses the above string and converts it into appropriate CanvasPathBuilder commands. It contains the following static methods

public static CanvasGeometry Parse(ICanvasResourceCreator resourceCreator, System.String pathData, StringBuilder logger = null);

The logger parameter in this method is an option argument of type StringBuilder which can be used to obtain the CanvasPathBuilder commands in text format. It is mainly intended for information/debugging purpose only.

Here is an example usage of the CanvasGeometryParser

private void OnCanvasDraw(CanvasControl sender, CanvasDrawEventArgs args)
    string data = "M8.64,223.948c0,0,143.468,3.431,185.777-181.808c2.673-11.702-1.23-20.154," + 
    var geometry = CanvasGeometryParser.Parse(sender, data);

    args.DrawingSession.FillGeometry(geometry, Colors.Yellow);
    args.DrawingSession.DrawGeometry(geometry, Colors.Black, 2f);

Check out the Sample Gallery project in GitHub where you can interact with the CanvasGeometryParser by providing the SVG/XAML path data and converting it to CanvasGeometry. You can alter the StrokeThickness, StrokeColor and FillColor of the rendered geometry.


You can view the CanvasPathBuilder commands called to create the parsed geometry.


Based on the SVG (Scalable Vector Graphics) Path language specification, the following rules must be followed to create the path data

  • All instructions are expressed as one character (e.g., a moveto is expressed as an M).
  • Superfluous white space and separators such as commas can be eliminated (e.g., M 100 100 L 200 200 contains unnecessary spaces and could be expressed more compactly as M100 100L200 200).
  • The command letter can be eliminated on subsequent commands if the same command is used multiple times in a row (e.g., you can drop the second “L” in M 100 200 L 200 100 L -100 -200 and use M 100 200 L 200 100 -100 -200 instead).
  • Relative versions of all commands are available (uppercase means absolute coordinates, lowercase means relative coordinates).

In the table below, the following notation is used:

() indicates grouping of parameters.

+ indicates 1 or more of the given parameter(s) is required.

Command Command Letter Parameters Remarks
MoveTo M (x y)+ Starts a new sub-path at the given (x,y) coordinate. If a moveto is followed by multiple pairs of coordinates, the subsequent pairs are treated as implicit lineto commands.
ClosePath Z none Closes the current subpath by drawing a straight line from the current point to current subpath’s initial point.
LineTo L (x y)+ Draws a line from the current point to the given (x,y) coordinate which becomes the new current point.
HorizontalLineTo H (x)+ Draws a horizontal line from the current point (cpx, cpy) to (x, cpy).
VerticalLineTo V (y)+ Draws a vertical line from the current point (cpx, cpy) to (cpx, y).
CubicBezier C (x1 y1 x2 y2 x y)+ Draws a cubic Bézier curve from the current point to (x,y) using (x1,y1) as the control point at the beginning of the curve and (x2,y2) as the control point at the end of the curve.
SmoothCubicBezier S (x2 y2 x y)+ Draws a cubic Bézier curve from the current point to (x,y). The first control point is assumed to be the reflection of the second control point on the previous command relative to the current point. (If there is no previous command or if the previous command was not an C, c, S or s, assume the first control point is coincident with the current point.)
QuadraticBezier Q (x1 y1 x y)+ Draws a quadratic Bézier curve from the current point to (x,y) using (x1,y1) as the control point.
SmoothQuadraticBezier T (x y)+ Draws a quadratic Bézier curve from the current point to (x,y). The control point is assumed to be the reflection of the control point on the previous command relative to the current point. (If there is no previous command or if the previous command was not a Q, q, T or t, assume the control point is coincident with the current point.)
Arc A (radiusX radiusY angle isLargeFlag SweepDirection x y)+ Draws an elliptical arc from the current point to (x, y).
EllipseFigure O (radiusX radiusY x y)+ Adds an Ellipse Figure to the path. The current point remains unchanged.
PolygonFigure P (numSides radius x y)+ Adds an n-sided Polygon Figure to the path. The current point remains unchanged.

The latest code is available in GitHub and the Nuget package is available here.

Happy Holidays! 🙂



In this post, I will be introducing you to another project of mine which I started this month in GitHub – CompositionExpressionToolkit.


Since Build 2016, I have started looking into Windows.UI.Composition APIs. These APIs are present in a layer between the XAML layer and the DirectX layer. They provide more powerful features than the XAML layer and also have a less steep learning curve than the DirectX layer. Composition APIs help to make your UI faster and more fluid. They definitely add a wow factor to your UI which might have not been possible with coding entirely in XAML.

If you are still unconvinced about Composition APIs, read the Why even use Composition Section in this blog. (TL;DR Composition APIs work outside your application process and will continue to render animations at 60 FPS even if your UI thread is blocked!)

So you might be wondering where CompositionExpressionToolkit fits in. Well, according to MSDN, ExpressionAnimation and KeyFrameAnimation use a mathematical expression to specify how the animated value should be calculated each frame. The expressions can reference properties from composition objects. Currently, the mathematical expression is provided in the form of a string. Expression animations work by parsing the mathematical expression string and internally converting it to a list of operations to produce an output value.

Well, using a string for creating an expression increases the chance of introducing errors (spelling, type-mismatch to name a few). These errors will not be picked up during compile time and can be difficult to debug during runtime too.

To mitigate this issue, we can use lambda expressions which are statically typed and allow the common errors to be caught during compile time. But how do you convert them to the appropriate string format to pass it as an input to the ExpressionAnimation / KeyFrameAnimation? This is where CompositionExpressionToolkit fits in. It provides several extension methods which take in a lambda expression as input and convert it to an appropriate string format which will be accepted by the ExpressionAnimation / KeyFrameAnimation.

CompositionExpressionToolkit also provides several other extension methods and helper classes which make it easier to work with Windows.UI.Composition.

Check out the CompositionExpressionToolkit GitHub page to know more details.

If you want to try out CompositionExpressionToolkit in your own project, it is available in NuGet too. To install CompositionExpressionToolkit, run the following command in the Package Manager Console in Visual Studio

Install-Package CompositionExpressionToolkit

Note: The current version of CompositionExpressionToolkit (v0.1.7.1) requires Windows SDK Preview 14332.

If you want to learn more about Windows.UI.Composition concepts then the following links will give you a good start –

WPFSpark v1.2.1.1 Released


Hello everyone. An update to WPFSpark has been released. WPFSpark v1.2.1.1 brings an update which allows ToggleSwitch control to show the current Windows Accent Color. It even dynamically updates its color when the user changes the  Accent Color.

For this purpose, I have split the ToggleSwitch Control Template into two – Basic and Modern. The ToggleSwitchBasicTemplate is to be used when you are displaying text within the ToggleSwitch control for the Checked and Unchecked state.


There is a predefined style using the ToggleSwitchBasicTemplate which can be used like this

	Style="{StaticResource {ComponentResourceKey TypeInTargetAssembly=wpfspark:ToggleSwitch, ResourceId=ToggleSwitch.Basic.Style}}" />

ToggleSwitchModernTemplate is to be used to emulate the look and feel of the toggle switch in Windows 10 Mobile and iOS.

There are three predefined styles using the ToggleSwitchModernTemplate –

  • ToggleSwitch.UWP.Light.Style – UWP Style ToggleSwitch for light background.
	Style="{StaticResource {ComponentResourceKey TypeInTargetAssembly=wpfspark:ToggleSwitch, ResourceId=ToggleSwitch.UWP.Light.Style}}" />
  • ToggleSwitch.UWP.Dark.Style – UWP Style ToggleSwitch for light background.
	Style="{StaticResource {ComponentResourceKey TypeInTargetAssembly=wpfspark:ToggleSwitch, ResourceId=ToggleSwitch.UWP.Dark.Style}}" />
  • ToggleSwitch.iOS.Light.Style – iOS Style ToggleSwitch for light background.
	Style="{StaticResource {ComponentResourceKey TypeInTargetAssembly=wpfspark:ToggleSwitch, ResourceId=ToggleSwitch.iOS.Light.Style}}" />

WPFSpark 1.2 Released

Happy New Year everyone!

Well last month has been really hectic and crazy (and filled with vacations). Though I released WPFSpark v1.2 on 1st Dec 2015, I couldn’t update my blog. I was busy with the UWP version of WPFSpark and hit a few roadblocks in the Nuget package creation for the same.


Check out my CodeProject article which describes the new features and updates that have been incorporated into the controls. You can obtain the Nuget Package from here. The source code repository is now shifted to GitHub. You can access it here.

Now for the UWP version. I have successfully ported FluidWrapPanel to the UWP version. I am trying to create a Nuget Package which contains the x86, x64 and ARM versions in a single package and based on the build configuration of the project using this library, the appropriate version will be selected. I am facing some issues (some folks are helping me out). Should be able to upload the UWP version by this week hopefully.

Happy Coding! 🙂

WPFSpark v1.2: Status

It has been almost two weeks since I started my work on WPFSpark v1.2 and here is the status so far:

SprocketControl, ToggleSwitch, SparkWindow, FluidProgressBar & FluidStatusBar have been successfully upgraded to .NET 4.6. Yay! Only FluidPivotPanel and FluidWrapPanel remain to be upgraded. ToggleSwitch has been rewritten from scratch and has more robust features now. It demanded my biggest attention and it caused the ClipBorder class being rewritten from the scratch too. Compared to these classes, the other controls have been incorporated with fewer changes.

Once I complete the .NET 4.6 version, porting it to .NET 4.5.2 should not take much time. What might take more time instead is combining these two into a single solution using the Shared Project template. I am still doubtful about it. If it takes longer to achieve it, I might postpone it and release the two versions separately now (one for 4.6 and the other for 4.5.2).

UWP version of WPFSpark might get delayed! Let’s keep our fingers crossed!

Back to code!

Back again

Hi everyone!

My last post was in January 2013. It been a long time since then and a lot has happened in my life too in the past few years – changing jobs to changing location! I couldn’t devote much time to my pet projects & my blog. But now I am back once again with some good news.

I have once again starting giving time to my projects and the first fruit of this labor is the NVM# project which is a complete rewrite of my NVM project (my first project when I began my adventure with .NET) for the Windows 10 OS. It has the same look and feel of the Settings app and provides an effective way of managing and sharing your Environment variables.


You can read more about it in my CodeProject article here.

Many folks have been asking me when I am planning to release WPFSpark v1.2. First of all, I would like to apologize for the delay in releasing v1.2. Second, it gives me immense pleasure to know that people are really liking my WPFSpark library and are eagerly waiting for the next version. Well the good news is I have begun working on v1.2 and am hoping to release it by the end of this month (November, 2015). Here is my plan of action for v1.2

  1. Bug fixes that have been reported in Codeplex site.
  2. Prioritizing of new features requested by users.
  3. Moving codebase to GitHub. Yes I will be moving the code to GitHub because I find it easier to use and collaborate there. Moreover, Visual Studio 2015 provides great integration with GitHub. It is the main reason I released NVM# in GitHub.
  4. UWP version of WPFSpark. Yes there will be a UWP version of WPFSpark! However not all controls will be ported at one go. Instead they will be added incrementally. I am still contemplating whether to port some of the controls like ToggleSwitch and FluidPivotPanel as there are similar controls available in UWP. The good news is that I had already ported FluidWrapPanel to WinRT for my FloTiles app and it will be the first one to be ported to UWP.
  5. I am still investigating on how to create a single code base for WPFSpark in GitHub which can cater to multiple dot Net frameworks and UWP. The Shared Project Template in Visual Studio might come handy. I am still investigating on that!
  6. Speaking of multiple dotNet frameworks, I am currently planning to release v1.2 for .NET 4.5, 4.6 and UWP. I haven’t decided whether to release for .NET 4.0. (Folks, do let me know! I might add it later)

Well that’s it for now! I will be back with more good news soon!

Time to code!

WPFSpark @codeplex

I have started a new project at The project is called WPF Spark.

You can access it here.

This project will contain a library of user controls, written in WPF, which can be used to enrich applications.

As of now, I have planned to develop a circular progress control (which I have termed as SprocketControl), an autocomplete textbox with some extra features, and a bislider control (which can be used to specify a range of values).

I have rewritten the Circular Progress Control and implemented it in WPF. I didn’t want to name it WPF Circular Progress Control so I came up with the name SprocketControl. The  first version of SprocketControl is ready and has been released at CodePlex.

In the next version of SprocketControl, I am planning to add features which will enable you to define the shape of each of the spoke in the control.

I am still exploring the depths of WPF… soon I will be releasing the rest of the planned controls… 🙂