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?
Ira Lukhezo's blog 
Can you suggest an alternative control vendor that understands the WPF paradigm?
Hello Ira,
Thank you for taking the time to put your thoughts and experiences in writing. To help us better understand the issues you encountered, would you be able to provide us with some specific examples, APIs, and scenarios with regards to the MVVM implementation?
Hello Ira,
Thank you so much for your comments. I must admit that, being new to WPF development I have found extremely helpful the DevExpress Controls. Even that I’m a Winforms developer and more recently an ASP .Net developer I have experienced some of the annoyances you describe here.
Currently, in my new project, I’ll be using DevExpress for their chart controls. Do you have any other recomendation (as DeveloperDan ask for).
Hello Edgar,
I am working on a scientific application whereby one of the first reasons my customer went for the Dev Express was for the Charts. After a few days we ended up using the open source ZedGraph as we found that DevExpress and most other peoples WPF charts could not render 1500 floating points of data very quickly.
If you require a simple chart not rendering a lot of data, or if speed is not an issue then sure use DevExpress. Recently there are WPF charts like http://oxyplot.codeplex.com/ that are geared towards scientific data, but the project is in its infancy so nothing you could really rely on.
My personal feeling is that there is no need to use any third party controls in WPF anymore, especially since there is a Datagrid and Ribbon, but if you require a specific charting library and DevExpress appear to meet your requirements, then sure go with them. They are an excellent company, with probably the best reputation in the business. I would rather direct the license fees towards a WPF design agency to create themes for my application as the in built controls offer enough extensibility, especially if you have developers that can use Expression Blend.
I must however reiterate that my intent is not to rubbish DevExpress unnecessarily, in Winforms and ASP.NET – both technologies I have a lot of experience in – they really do provide value for money, and reduce the time it takes to ship products. In WPF they are far less necessary, and this can easily be illustrated by their lacklustre roadmap for WPF for this year (2011).
Try having a look at their website and see it anything really new and exciting is due in the next year and you will find very little if any new or innovative development going on.
Abject frustration is EXACTLY what I experienced thanks to DevExpress. I lost hours of my life attempting to simply bind a combo box. The drop-down list at best would only display my ItemsSource class name multiple times. I even posted a StackOverflow question to figure out what I could possibly be doing wrong. Finally on a whim I tried removing this one line of xaml:
devx:ThemeManager.ThemeName=”DeepBlue”
Suddenly my problem went away. It was caused by the Developer Express wpf theme DeepBlue. Discovering the problem was a tremendous relief. My company will now be using Telerik WPF controls. My colleagues are quite happy with DevExpress Asp.Net controls. It is only the WPF suite we are avoiding.
http://stackoverflow.com/questions/5702773/wpf4-is-this-indictment-of-devexpress-wpf-controls-valid-and-what-is-a-good-alte?tab=active#tab-top
Hi DeveloperDan,
I got bitten by that bug too, it seems that they decided to change the name of one of their themes in one of their out of band builds. They also played around with the theme files (moving code in assemblies) so it may be that you are not referencing the correct one. I think if you change the theme name to “Azure” then you may get the behaviour you require.
DevExpress have been responded and stated that they are looking at creating some guidance on top of modifying their controls where possible to support the pattern. I am waiting with anticipation for their first 2011 release as we will be shipping in a few months, and this is the last time we can update our dependencies and hopefully tidy up some code. If time were available, I would have liked to have worked with DevExpress to whittle out any issues I have, but, unfortunately, I have found little time to supply feedback to them as I always think people that complain should also propose solutions and highlight issues, rather than using hyperbole and frustration as the sole method to affect resolution, it is seldom productive.
I will certainly review their subsequent releases and link back to this post, as I do have really high regard for DevExpress in general, but have found an episode that I would rather not go through again.
Regards,
Ira
I have to agree it is incredibly painful trying to do MVVM with their controls. Everything is event based with status in the event params. So say you have their grid and want to be notified when the row selection is changed you can either subscribe to the event, but this won’t work with eventtrigger mapping as you can see the contents of the event. So then you think, I’ll try binding to the selectedrows collection directly. But… you can’t do that either.
So then you end up having to work directly with the events which is undermining the elegancy of mvvm.
I would also like them to consider implenting IObservable on all their container types etc, then we can use reactive extensions. Simply bind to containers like the SelectedRowsCollection which could offer a RowAdded IObservable and then bind to that with a rx subscribe. This is how it should be done!
sorry should be ‘you can’t see the contents of the event’
Hello Dan H,
It is possible to bind to the selected row in the grid by creating a “SelectedItem” in the view model (like a treeview or combobox) and then using the FocussedRow property on the TableView e.g. FocusedRow=”{Binding Path=SelectedItem, Mode=TwoWay}”.
I also don’t think it is worth DevExpress supporting Rx (yet) because this is likely to remain a library and not be added to .NET because Anders Heijsberg the Chief Architect of C# does not like Rx as it forces developers to have to think differently (this may change if a different abstration is worked out)
The biggest issues I have with the datagrid are that you cannot bind to standard .NET data structures like dictionaries that you can do with lesser controls like a listbox or listview as demonstrated here http://stackoverflow.com/questions/4251183/wpf-two-dimensional-datagrid-listview, it is absolutely ridiculous
I detest the fact that you have to bind to a FieldName where in the rest of WPF you can have a DataContext as this places an artificial limitation on the grid columns whereby it is just good to bind to data from a database. If this is not your setup (like my company – we have our own file format and data structures and not database). I have created my own Pivot formatting like the example above because I need to display scientific data multi-dimensionally and DevExpress grids just are not up to the job, their PivotGrid (renamed to OLAP) only work with a database, and is ReadOnly. To quote Liskov, their grids walk like ducks, quack like ducks but need batteries.
Thank you for this article. I have been working with DevExpress controls for WinForms for about 2 years, and quite happy with the results, although their object model is not what I could call intuitive though.
Since a couple of months ago I’m designing a totally new project and chose WPF for developing it. I am a totally newbie in WPF so I thought I would make sense instead of start from scratch, trying to reuse the current skills I got from DevEx in winforms.
Thanks God I didn’t write one single line of code, somehow I know they didn’t make a nice implementation. Now, with your post it’s a fact.
I think I won’t be using another 3rd party again. Perhaps the charts need that, for the rest of the project, no way. I better purchased Expression Blend and try to learn how it all works with regular WPF.
I had withdrawn this post, but due to this post http://channel9.msdn.com/Forums/Coffeehouse/Has-anyone-here-used-DevExpress-XAF-Looking-for-Opinions I have decided that I am entitled to have an opinion, even if it is at variance with DevExpress.
You will also bang your head against a wall with Devexpress Winform Controls sometimes – the yjust don’t do everything like the normal VS controls, and then declare that their way is right. If you then cannot do something there is always a workaround by the support.
I don’t know about their WPF control but this company definitely lacks the professionalism and competence I require from a third party component provider.
Some of their components swallows exceptions thrown inside event handlers. If, for example, you want an autosave feature in the XtraGrid, you will not want to use it’s RowUpdated event because if anything goes wrong and isn’t handled properly, the grid will silently occult the problem and act as if everything was normal.
I’ve reported this behavior and was told it was by design. Exception swallowing by design!
I can’t take this company seriously anymore. And it’s sad because I invested a lot of time and effort in it.
I know it’s been months since I’ve posted the above comment, but I’d like to set some things straight for the sake of fairness.
Within nine years doing business with this company, I’ve seen it standing way above the competition in many areas. I remember seeing features appearing on their grid before anyone else’s in the market. For years, their support service has been top-notch. Plus, their IDE productivity tools (CodeRush and Refactor!) are IMHO the best in the market as of today (sorry, Resharper lovers 🙂 ). I learned a lot of things looking at their code and became a better developper in the process.
It’s only since a few years back I started feeling a rupture. And I wasn’t alone, obviously.
By the time I wrote the above comment, I had lots of accumulated frustration over a lot of things from DX. I won’t go into details here but I tried reaching out to them for a long time about it, using different channels and tones, without the desired results. Out of despair and frustration, I started renting here and there, hoping it would eventually be shaking the tree hard enough so that somebody would finally do the right thing.
It was around that time that Ray Navasarkian, chief executive at DevExpress, had the much welcomed initiative of calling me to discuss about my issues. Again, I won’t annoy you with the details (there would be a lot to say), but some very good stuff came out of this discussion and the follow-up he personnally made afterwards. Overall, he spent hours listening to what I had to say.
Anyone out there doing business in IT (or just any business for that matter) knows how precious this kind attention is. Especially given that I work for a very small company that buys a single developer license, and that my english isn’t that good.
So to recap: there’s no denying that DevExpress, in the last years, had some serious flaws in their communications with customers. Still, I think that the way I talked these guys down is not quite fair: this company allowed me to do some pretty amazing stuff in the past, and still does today. They know their success is tied to their customers’s and they do want to help them succeed. They can (and WILL) surprise you.
Whoever is reading this hoping to get some clues about which company should be their next component vendor should AT LEAST give their trial version a chance.