Should I use DevExpress WPF controls for a new project?

Firstly, I must draw attention to the fact that my intention is not to spew bile, or communicate zealot-ism of any shape or form. My intention is to try and provide a fair, concise and balanced view, relative to personal experience that may hopefully assist anyone looking to answer this question.

Presently, I am now nearly six months into a Greenfield project, written exclusively using DevExpress WPF controls. Over the last few months, I have come to know their WPF API’s particularly well, and will continue to use the controls for the lifetime of the project simply because it is too late. A definite consideration is that it is often impossible to change anything major as a third party software suite you are developing on top of midway, for all sorts of reasons, the most notable being expense and time/delay to finish. WPF is such a flexible platform, I would advocate getting the business logic and functionality of an application thrashed out first, then look to a design team or third-party suite right at the end the end or during the process, rather than automatically restricting oneself from the offset with a third party suite. This, however, is seldom practicable, as the product owner/customer will need to be interacting with the software as time progresses, and they want to see something pretty, there is hardly ever any flexibility here, the application has to look stunning very soon into the start of the project, in order to gain their confidence (and settle their nerves) and continue in this vein.

There is nothing like hindsight, a trite but often unavoidable word when reflecting on a projects progression, It is always harder to be objective at a later date, because quite often, a quite different set of circumstances and considerations result due to the fact that time has moved on, and better ways of dealing with technical challenges and vendors present themselves. the steps required to solve particular problems become perspicacious.

One also must accept that projects must commence at some point, and utilise the best that is available at the time, otherwise no-one would ever start anything, because a better suite of components are just around the corner. Invariably, there have been profuse technical challenges along the way, as the application is a scientific one, but that is the essential stimulus for me personally,  yes, not fun some days, and you have good days and bad ones, but the overwhelming sense of achievement in surmounting the obstacles are what makes one do it again and again. Attention to minute detail is of unparalleled importance.  For all intents and purposes, it is about minutiae!

I think it important to take note that this is not a typical forms over data application but of a scientific bent, and thus far, their controls have proven very hard, if not impossible to customise to meet our technical requirements and specifications with ease and eloquence. Over the last month or so, I have been writing code that I quite frankly feel embarrassed to ever admit that I checked in…why?

The biggest problem is that DevExpress developers completely misunderstood WPF when they developed their WPF controls. I really cannot impress upon you sufficiently well just how much of a displeasure it is using their controls. I feel absolutely terrible (almost guilty) about talking about a vendor with such negativity, but they have made a serious mistake in their WPF suite, it has been a singular source of the most abject frustration for me in about a decade of developing software. WPF was built to allow developers to be flexible, and to build components with ease, using DevExpress controls cuts your flexibility by about 90% (and that is not a guesstimate).

Frequently, it is possible to get off to a bad start in any project, even with experienced developers. It is the fresh ideas and perspicacious vision that allow younger developers for the most part to escape the nebulous approach experienced developers tend to exhibit. In my experience developing WPF applications over the last three years or so, one of the most poisonous components to introduce to a new  WPF application, is a dyed-in- the-wool Windows Forms developer. One feels however that one must communicate extensive and comprehensive experience as a Windows Forms developer, but  somehow I managed to shake off any misdirection in solving WPF problems after witnessing just how bad approaching WPF from a C++ and Windows Forms mentality is. On some projects, I have witnessed resplendent software engineers and architects commit the gravest mistakes in implementing WPF projects, simply because they could not and would not start looking at things from a different direction. It is this scourge that has been eminent in the procurement for DevExpress WPF controls, that much is irrefutable.

Recently, after speaking with a colleague, we arrived at the conclusion that their WPF API’s have been written top down by Windows Forms developers. It is that, and their overwhelming success as Third Party Windows Forms Vendors where things have gone horribly wrong. Using their controls in most instances, places asphyxia on whatever problem you are trying to resolve, because most of their API’s are just so hard to get to do what you want them to do, because they failed to grasp what WPF developers expect in their components. Frequently, I consult my rather extensive library of code to solve problems that I find cropping up again and again, but it is almost impossible to use any of my  existing WPF code with their controls, because of the way they have implemented their API’s. That is a sad indictment of the API’s. A simple application that you write in WPF and bind to in an items control or List Box in WPF, is impossible to migrate to their Grid controls for example because of their horrendous implementation.

One of the key components in every WPF project that I have worked on is Model View View-Model (MVVM) proficiency. This has been an essential and sought after skill when dealing with customers. As I write today, you will find plethoric requests for MVVM support for their WPF controls, and hitherto there is none. There are no code samples or examples on their numerous websites, so typically you will confront a problem, and find that their controls are specifically written to handle events in the code-behind and not commands. You will also find that they adore the decade old version of ADO.NET that is datasets. I have not worked on a single WPF application that has not used MVVM or POCO’s, finding anything in their documentation or code samples using POCO’s is as likely as finding a hen with teeth, speaks French, and tells jokes.

Their WPF Ribbon is a prime example of being a complete dog to work with. It is incomplete, non-MVVM compliant, and when customers say their want an Office 2010 Application Menu for example, your sat left wondering, why you paid the money for the controls. Using it in your applications is a factory for writing tightly coupled hard to modify code, and if you do create workarounds you find that you have a polluted codebase, trying to get a MVVM application that is easily testable. Whilst we are on the subject of testing, try to find a single example of a WPF component of theirs in a test situation, I will save you the time, and regrettably advise you that there are no code samples, nor do their components help one build testable code. DevExpress almost obstinately choose to ensure that you develop the hardest to maintain and poorly separated code, by creating components that cultivate bad practices. If you are a design oriented software team or company, you will find that DevExpress only supply asphyxiation to your ability to progress, you can take out the ”express” and replace it with “Dev-Stress” or “Dev-Stressed”

What I cannot however fault, is their support, this is certainly a redeeming feature, because their have an absolutely brilliant support system, and their staff are a joy to work with. They almost always find a solution for a query, though sometimes one is left wondering why  you needed to consult someone to perform what are mostly basic functions.If you are thinking of using their controls then you must be prepared to accept that you are for the most part, a paying guinea pig, because most of the issues you will have have either been reported by other customers, or your problem will be used to resolve other peoples problems in the future, as their websites and forums are pretty useless, they seem to take little care in preparing helpful documentation and code samples that reflect real world usage for their customers, pretty much every example is an example on how not to write quality software.

Another big issue I have found is with their release cycle. They generally have two big releases every year, and lots of incremental ones. If you find a bug, it is always tempting to update to their bug fix versions, but I have found this to be an endless source of hair-loss. Pretty much every time I have upgraded to solve an issue, it has been partially fixed, or ended up creating bugs or their have renamed and changed things that break things. The Visual Studio way of releasing software seems the best for developing complex projects, where over the period of a year or so, you can concentrate of solving the domain problems, rather than bug-riddled releases. It may sound as If I am being harsh or truculent, but this is the reality of using their software.

If you are thinking of using DevExpress WPF controls, you really have to try and assess whether you fall into their 90% use case, or their 10% oddities, but even if you do fall into their 90%, their API’s will assist you in writing a lot of hard to test, inelegant and expensive to maintain code, as they have been written to work best using the paradigm of the technology they are meant to be replacing (Windows Forms). If you have worked with WPF for any amount of time, it is almost unbelievable just how restrictive their controls are to use. Presently, even as one writes, befuddlement  continues to present itself, as to how or why their controls work the way they do? The Microsoft WPF control library is such a flexible system, why asphyxiate you and your organisations software development efforts by people that still write software components as if it was a decade ago?

WPF Message Box

The default MessageBox in WPF looks rather ugly on Windows 7 and Windows Vista







In order to update the messagebox, add a new app.manifest file


ensure you have the following dependency tag

    1 <?xml version="1.0" encoding="utf-8"?>

    2 <asmv1:assembly manifestVersion="1.0" xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv1="urn:schemas-microsoft-com:asm.v1" xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:xsi="">

    3   <assemblyIdentity version="" name=""/>

    4   <description>iDesign – Media Burner</description>

    5   <dependency>

    6     <dependentAssembly>

    7       <assemblyIdentity name="Microsoft.Windows.Common-Controls" version="" type="win32" processorArchitecture="*" publicKeyToken="6595b64144ccf1df" language="*" />

    8     </dependentAssembly>

    9   </dependency>

   10   <trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">

   11     <security>

   12       <requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">

   13         <!– UAC Manifest Options

   14             If you want to change the Windows User Account Control level replace the

   15             requestedExecutionLevel node with one of the following.


   17         <requestedExecutionLevel  level="asInvoker" uiAccess="false" />

   18         <requestedExecutionLevel  level="requireAdministrator" uiAccess="false" />

   19         <requestedExecutionLevel  level="highestAvailable" uiAccess="false" />


   21             Specifying requestedExecutionLevel node will disable file and registry virtualization.

   22             If you want to utilize File and Registry Virtualization for backward

   23             compatibility then delete the requestedExecutionLevel node.

   24         –>

   25         <requestedExecutionLevel level="asInvoker" uiAccess="false" />

   26       </requestedPrivileges>

   27     </security>

   28   </trustInfo>


   30   <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">

   31     <application>

   32       <!– A list of all Windows versions that this application is designed to work with. Windows will automatically select the most compatible environment.–>


   34       <!– If your application is designed to work with Windows 7, uncomment the following supportedOS node–>

   35       <!–<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>–>


   37     </application>

   38   </compatibility>


   40   <!– Enable themes for Windows common controls and dialogs (Windows XP and later) –>

   41   <!– <dependency>

   42     <dependentAssembly>

   43       <assemblyIdentity

   44           type="win32"

   45           name="Microsoft.Windows.Common-Controls"

   46           version=""

   47           processorArchitecture="*"

   48           publicKeyToken="6595b64144ccf1df"

   49           language="*"

   50         />

   51     </dependentAssembly>

   52   </dependency>–>


   54 </asmv1:assembly>


Burning and Erasing CD/DVD/Blu-ray Media with WPF

Edit 22AUG2017, since the initial source on CodePlex is about to be shut down, I have moved this project to git available here:

I have also modified the theming a little










Original Post:

Some time ago I worked on a project where I needed a DVD burner/formatter, and came across an open source version by Eric Haddan. The only problem with that excellent solution was that it was written in winforms ,and I was working on a WPF application. I have now ported that application to WPF using MVVM.


You can download the free WPF burner at Just select the downloads tab and save the source code.

If you are on XP then you will need Image Mastering API v2.0 (IMAPIv2.0) for Windows XP if you don’t have this already (this is included in Vista SP2 and Windows 7). To burn a Blu-ray you will need Windows Feature Pack for Storage 1.0 if you are not using Window 7.

Common sense lost with MVVM

I am a big fan of using MVVM in WPF applications, but am finding, increasingly,  that even seasoned developers frequently dispose of very good habits, in order to stay true to the pattern.

One such occurrence is is not using message boxes. A  cardinal sin in MVVM, is ensuring that message boxes are never used in View Models. The end result is that one starts to see code like this.


If you don’t have a logging system for your exceptions then you should have, if you do then always ensure that you log the exception. During development, one instinctually starts to determine brittle code, and events where errors can occur and use try-catch blocks. The worst thing you can do here is nothing. It is better not to use the try-catch at all, and just let the application blow-up, because at least you know that there is a problem, and go about fixing it.

I really cannot sufficiently impress upon thee just how much of a bad practice this is, and the amount of time you or other developers that work on your project will spend trying to find obscure bugs that occur because you are swallowing exceptions, just because MVVM stipulates that message boxes should not be used, means they shouldn’t, they should!

Free WPF Ribbon with source code and MVVM samples

Finally after about 2 years as a CTP, Microsoft have released the WPF ribbon. Due to the delay, one can be certain that they were allowing their third party software vendors as much traction for users that needed a ribbon, but some brilliant open source versions including Fluent Ribbon Control Suite have been developed.


The best thing about the release, is that the Office Fluent UI licensing is now no longer a requirement. This allows people to download the software straight away, without having to go through the cumbersome process of logging into the Office website, signing the licensing, then spending half a day trying to locate the installation because it was hidden in a way that made you think they don’t want anyone to use it.

The download for the ribbon is available here. Please ensure that you also take the time to install the source and samples if you want to build MVVM compliant applications with the ribbon (you should be doing this in WPF anyway) . The MSDN documentation is available here.

The installation notes say that this is not supported on XP, but on vista upwards but I have not tested this. If there are issues then you should be able to use another vendor.

After installing the MSI you should have the following template in Visual Studio


There is no information on the installation templates for the express editions, but I would hazard a guess as to them never being available, as building applications with a Ribbon is not something a learner ‘typically’ does. If you are using express, then you should be able to add the requisite .dll thus. If you look in my Tree View below in Visual Studio, you will find that there is a reference to RibbonControlsLibrary. This is located at; C:\Program Files (x86)\Microsoft Ribbon for WPF\v3.5.40729.1\RibbonControlsLibrary.dll


Note:  If you installed the source and samples as well, a .zip file with both is available at the same location. Copy this, and unzip it in a location of your choosing


The code behind for my window has the following code, so inherit off RibbonWindow


Finally your XAML should be defined so, and you’re good to go!


WPF and Silverlight Timer

Users of Windows Forms will know that there are three timer objects you can use, namely the Windows Forms Timer, the System Timers Timer and finally the System Threading Timer, as the following example demonstrates;

Note: this tutorial is in both C# and Visual Basic, so look beneath the Visual Basic examples for the C# Version.

Visual Basic

Public Class Form1


    Dim timerCallBack As System.Threading.TimerCallback


    Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load

        ”Winforms Timer

        Dim wfTimer As System.Windows.Forms.Timer()


        ”Timers Timer

        Dim tTimer As System.Timers.Timer()


        ”Threading Timer

        timerCallBack = AddressOf PrintTime

        Dim thTimer As System.Threading.Timer = New System.Threading.Timer(Me.timerCallBack)



    End Sub


    Private Sub PrintTime(ByVal obj As System.Object)

        ”Print the time to screen

    End Sub



End Class


using System.Windows.Forms;


namespace TimersExample


    public partial class Form1 : Form


        System.Threading.TimerCallback timerCallBack;


        public Form1()




        private void Form1_Load(object sender, System.EventArgs e)


            // Winforms Timer

            System.Windows.Forms.Timer wfTimer = new Timer();


            //Timers Timer

            System.Timers.Timer tTimer = new System.Timers.Timer();


            //Threading Timer

            timerCallBack = new System.Threading.TimerCallback(PrintTime);

            System.Threading.Timer thTimer = new System.Threading.Timer(this.timerCallBack);


        private void PrintTime(object obj)


            //Print the time to screen






In both WPF and Silverlight there is a new timer (the fourth .NET framework timer) called the System.Windows.Threading.DispatcherTimer. To demonstrate how this works, look at the following simple code sample. In it, there is some XAML that declares a label, button and a button click and window loaded events (In Silverlight use the UserControl_Loaded event for the page instead of Window_Loaded).


<Window x:Class="WpfTimer.Window1"



   Title="Window1" Height="300" Width="300" Loaded="Window_Loaded">



        <StackPanel Orientation="Vertical">

        <Label Height="28" Width="70" Name="label1">Label</Label>

        <Button Height="23" Width="70" Name="button1" Click="button_Click">Button</Button>







Note that in the Visual Basic XAML you have Window x:Class="Window1" at the top (in case you’re wondering why the XAML does not compile). In the code behind, you have the following code that instantiates a DispatcherTimer in the load event of the Window, and allows a user from starting and stopping the timer by toggling the button click event.


Visual Basic

Class Window1

    Dim timer As System.Windows.Threading.DispatcherTimer

    Public Event UpdateTime()


    Private Sub Window_Loaded(ByVal sender As Object, ByVal e As RoutedEventArgs)

        timer = New System.Windows.Threading.DispatcherTimer()

        timer.Interval = TimeSpan.FromSeconds(1)

        AddHandler timer.Tick, AddressOf timer_Tick


    End Sub


    Sub timer_Tick(ByVal sender As Object, ByVal e As EventArgs)

        Me.label1.Content = DateTime.Now.ToLongTimeString()

    End Sub


    Private Sub button1_Click(ByVal sender As Object, ByVal e As RoutedEventArgs)

        If Not Me.timer.IsEnabled Then


            Me.button1.Content = "Stop"



            Me.button1.Content = "Start"

        End If

    End Sub





End Class



using System;

using System.Windows;


namespace WpfTimer


    /// <summary>

    /// Interaction logic for Window1.xaml

    /// </summary>

    public partial class Window1 : Window


        System.Windows.Threading.DispatcherTimer timer;


        public Window1()




        private void Window_Loaded(object sender, RoutedEventArgs e)


            timer = new System.Windows.Threading.DispatcherTimer();

            timer.Interval = TimeSpan.FromSeconds(1);

            timer.Tick += new EventHandler(timer_Tick);



        void timer_Tick(object sender, EventArgs e)


            this.label1.Content = DateTime.Now.ToLongTimeString();



        private void button_Click(object sender, RoutedEventArgs e)


            if (!this.timer.IsEnabled)



                this.button1.Content = "Stop";





                this.button1.Content = "Start";









Free Training worth £5000

It’s not often that you find something that is too good to be true, but this is. Microsoft are offering free Windows Presentation Foundation training by two of their leading proponents on the technology Jaime Rodriguez and Karl Shiftlett.

The agenda for training will be

Day One:

  • Lap Around WPF
  • WPF Tools ( Blend, Visual Studio 2008)
  • Graphics Subsystem
  • Layout
  • WPF Fundamentals and new concepts
    • Application Model
    • Dependency Properties
    • Trees (logical & visual)
    • Events
    • Threading
    • Resources
  • Controls
  • Styling
  • Templating
  • Q&A with instructors at end of day
  • Day Two:
    • WPF integration with Win32 and Windows Forms
    • Data binding
    • Introduction to Model-View-ViewModel
    • Commanding in M-V-VM
    • Views, Navigation and Transitions
    • Data Validation
    • Error handling, Model dialogs, Logging
    • Unit Testing
    • MVVM & LOB tips and tricks
    • Q&A with the instructors

I have signed up for this training, and think that it is a seriously good offer, that you won’t find anywhere, especially seeing as the training will be coming from the “horses mouth” so to speak!