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!

Visual Studio:TaskKill only if Process exists

My primary tool for development is Visual Studio. Often while building and testing applications, I have face the following scenario numerous times:

  • I build and run the application (Ctrl + F5).
  • I test my application and feel the need for some more changes in the code.
  • I go back to the code and modify and build again.
  • Visual Studio gives me the following error message:

Unable to copy file “MyApp.exe” to “\Debug\MyApp.exe”. The process cannot access the file ‘..\Debug\MyApp.exe’ because it is being used by another process.
Only then I realize that I had forgotten to close the application before rebuilding.😦

I was thinking of finding a way to automatically close the application before each build. Initially I put the command “taskkill /f /im MyApp.exe” in the Pre-Build events of the project but this worked only if the application was running. If the application was already closed, the build failed with an error message saying that the script failed with an exit code 1.

I then found another solution on the web (link). This still gave me the same error. So, I tweaked it further to arrive at this script:

tasklist /FI "IMAGENAME eq $(TargetName).exe" 2>NUL | find /I /N "$(TargetName).exe">NUL
if "%ERRORLEVEL%"=="0" (taskkill /f /im $(TargetName).exe
) else ( exit 0)

It proved very effective and time-saving too!

Note: The above script will work only if you are building an .exe application. If you are building a DLL, try putting the name of the application, which is using the DLL, in place of $(TargetName).

Happy Coding!:)

P.S. I found another simpler solution here

taskkill /F /IM $(TargetName).exe 2>&1 | exit /B 0

FluidMoveBehavior Bug (& Memory Leak!)

Update (May-06-2016): I am not sure whether this bug is fixed in the latest version of WPF. However, I have rewritten the ToggleSwitch control from scratch which completely avoids this issue. You can check it here.

Back in August, two people, tmccowan and Bullimann, brought into my notice a bug associated with the FluidMoveBehavior in WPF. This issue can be found here. Since one of the controls (ToggleSwitch) in my WPFSpark project was using this behavior, the issue was preventing the garbage collection of the control. According to the post, the static TagDictionary in FluidMoveBehaviorBase is holding references of the associated objects and thus preventing them from being GCed.

Steve Greatrex posted a workaround subscribe to the UserControl.Unloaded event and in the handler call the Detach method of the FluidMoveBehavior.
I tried this workaround and did a memory profiling with ANTS Memory Profiler  (a really great tool!). To my dismay, this workaround had little effect. I thought the Detach method would remove the reference of the ToggleSwitch’s internal Grid but it didn’t. So the instances of ToggleSwitch kept piling in memory each time they were instantiated. (see images)


I debugged the code and dug in deeper into the FluidMoveBehaviorBase to see the contents of the TagDictionary object. In this dictionary, the Key is the object to which FluidMoveBehavior is added and the Value is an internal class called TagData which encapsulates the following properties: The object itself(Child), the object’s Parent, ParentRect, AppRect, TimeStamp and InitialTag.
So I thought of a different workaround using Reflection. In the UserControl.Unloaded event handler:
1. Get access to the TagDictionary field in the FluidMoveBehaviorBase.
2. Invoke the ContainsKey method to check if the object is added as a key in the dictionary.
3. If ContainsKey method returns true, then invoke the Remove method to remove the object from the dictionary.

private void OnUnloaded(object sender, RoutedEventArgs e)
    this.Unloaded -= OnUnloaded;

private void DetachFluidMoveBehavior(DependencyObject depObj)
    if (depObj != null)
        foreach (var b in Interaction.GetBehaviors(depObj).OfType<FluidMoveBehavior>())
            b.IsActive = false;
            // HACK: This hack is to remove the depObj from the TagDictionary collection using reflection as 
            // the TagDictionary collection is holding up the reference of depObj leading to its non-garbage collection of depObj (a.k.a Leak!)
            FieldInfo fieldInfo = typeof(FluidMoveBehaviorBase).GetField("TagDictionary", BindingFlags.Static | BindingFlags.NonPublic);
            if (fieldInfo == null)

            // Get the TagDictionary object
            var tagDict = fieldInfo.GetValue(b);

            // Get the ContainsKey MethodInfo
            MethodInfo miContainsKey = fieldInfo.FieldType.GetMethod("ContainsKey");
            if (miContainsKey != null)
                // Does the TagDictionary contain depObj as a key?
                bool containsKey = (bool)miContainsKey.Invoke(tagDict, new object[] { depObj });
                if (containsKey)
                    // Get the Remove Method Info
                    MethodInfo miRemove = fieldInfo.FieldType.GetMethod("Remove");
                    if (miRemove != null)
                        // Remove the depObj from the TagDictionary
                        miRemove.Invoke(tagDict, new object[] { depObj });

Though this is a crude solution, it does its job.

This workaround has been incorporated in WPFSpark v1.2 which I will be releasing soon.

I hope Microsoft fixes this issue in the next release.:)

FloTiles v1.0 released!


I am really excited to say that the next game which I was working on is finally complete and released in the Windows Store. It is called FloTiles  and it is a Windows 8 Metro application. It is also my entry to The Windows 8* & Ultrabook™ App Innovation Contest sponsored by Intel and hosted in CodeProject.

There were two rounds in this contest. In the first round, we had to write an article in CodeProject summarizing our idea for the app for this contest. Based on that, Intel would be providing us an Ultrabook as a 3 year loan. I passed the first round and got the Ultrabook within a few weeks. The deadline for the second round was Nov 21 for the app to be submitted to either the Windows Store or Intel’s AppUp store. But the judging would be done only after December 1st. This gap gave me ample time to add more tweaks and features to my first submission.

You can read in detail about the FloTiles game in my CodeProject article which I updated yesterday. It is the longest article I have written yet as it details the various components and  features incorporated during the development of this app.

The FloTiles game is available for download from the Windows Store here.

Accessing Dropbox via .NET

One of my recent assignments involved storing of a configuration file in Dropbox so that it can be accessed by my application from anywhere around the world. This was a new area of exploration for me as I had no idea how to make a .NET application communicate to Dropbox. This gave me an opportunity to learn something new and I jumped at it.
My first step was to create a Dropbox account and go through their documentation of the REST APIs. Dropbox does not have an official SDK to access it via .NET (though third party libraries are available).
The next step was to search online. Surely, someone would have faced a similar problem and someone else would have suggested some solution to it. I visited several forums where people had posted questions on this issue.
One such forum led me to Christophe Geers’ Blog. This guy has done a tremendous job of writing a series of excellent articles describing the various steps you need to perform to get access to the Dropbox account, creating of folders, uploading and downloading of files, etc. These articles are what a beginner needs to get an solid understanding of programmatic access to DropBox. The accompanying source code is an added bonus.
Do check out his articles here.