My company is starting a major greenfield development project using DevExpress WPF controls. I just read this critical review of their WPF controls:
[…] 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.
Do you agree that DevExpress does not understand the WPF paradigm and will cause our developers grief during development and maintenance? Can you suggest an alternate vendor of WPF controls? I'm looking for a vendor with WPF controls that will enhance our application while fitting well with the WPF API, binding and MVVM.
The link (above) to the critical blog post is broken. The original author has stated:
I wrote the original article, and have decided to work with DevExpress in a private capacity after speaking with them so I have regrettably decided to remove the post. Regards, Ira
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.
I would like to clarify our opinion on usage of our controls in applications built based on the MVVM pattern. At the moment, we are working on a series of examples which should clarify how our controls can be used under different popular MVVM based frameworks (like Prism, MVVM Light and so on). There are a couple of problems in our WPF controls regarding the MVVM pattern and we are trying to eliminate them. However, generally there are no showstoppers that can prevent a developer from using our controls in a MVVM application. Hopefully, our examples, posted on the DevExpress Web Site will convince you in this.
I do not agree completely with the assertion that DevX developers missed the mark on WPF. However, I will say that it appears they may have had a steep learning curve to overcome. Lets face it, WPF is massive. To master it, even out of the box, is a daunting task. I do agree that DevEx controls will not fit into a MVVM pattern, but they do sit quite nicely in a MVP pattern. "Can you suggest an alternate vendor of WPF controls?" No, but I will suggest that you study additional patterns if you are stuck with DevEx.
I have used Syncfusion, Ingragistics, Telerik as well as various smaller libraries and DevExpress is my platform of choice. I find them to be not only super supportive of WPF and MVVM but their tech support has been phenomenal. I actually was mid project in a multi-million dollar project using Syncfusion WPF and found so many bugs in the library that my customer was close to pulling the plug. I switched mid stream to DevEx and they save my bacon. Their controls always seem the most up to date and incorporating the latest trends. I wish they did more Xamarin stuff and some of the other things that Syncfusion does but I would rather have less stuff that actually works than a wide array of stuff that doesn't.
Related
I saw a lot of question on this topic and it took me some time to decide whether or not I would write another one ... but I think my question is a bit more complicated ... so here we go.
I'm currently working with a WPF application using MVVM.
The application is built with:
WPF
Prism V2
Ideablade (devforce) to access a database
Avalon dock for the docking feature
Telerik for the grid component
Views and ViewModel are generated with .tt file.
Views are generated in xaml (for WPF) files.
I know that:
Telerik has Silverlight controls
Using Prism V2 will probably help me doing a Silverlight version of the application
I don't know:
If the usage of devforce can be a show stopper
If the usage of avalon dock can be a show stopper
My question:
Appart from generating xaml for Silverlight ... where do I start ...
----EDIT----
Please, avoid any comments like "Silverlight will die" or "Silverlight xaml is a subset of WPF xaml".
It is a proof of concept and should be made using Silverlight. For the xaml, I can modify the application to use only simple ui element that can be both in Silverlight and WPF.
Depending on how you actually used Prism and other frameworks this can be a lot of work or quite easy.
I'd start at the 'bottom' because I'd expect the Models and ViewModels to be quite portable, at least that is what I have experienced so far. She fact that Silverlight more or less forces you to write async code everywhere might encourage you to investigate in (yet another) framework such as Rx
The Views could be quite a hassle; you will have to find controls that provide the same features that you are using in WPF, build them or invent something new. That can be a lot of work.
Another thing to consider is when your WPF app relies on many desktop features you might consider creating an Out of Browser Silverlight App.
As with any project try to find areas that will probably need a lot of attention and do those first; it's a waste of time to get a lot of stuff working to find out later that you will have to replace it because of an impossibility elsewhere.
I am planning to learn XAML. I wanted to know if I should first learn about WPF and then start XAML?
Please advice.
It depends on what your future plans are with XAML/WPF. If you want to get up and running and use it as quick as possible you might consider starting with XAML and WPF at the same time (but note that you can't learn or use WPF just be learning about XAML).
If you plan to work with XAML/WPF for a long time and you will have a lot of WPF projects ahead you probably should consider starting with "pure" WPF.
I belong to the latter camp and it helped me a lot to first get to know the WPF object model, rendering and layout system and then start with XAML, styles, templates etc. For me it made thinks easier to understand (and there is a lot to understand). I understood that XAML is just another way to represent/serialize a .NET object graph that is built as a layer on top.
This is also the way Charles Petzold's book is structured and I think it is the perfect book to start with when you want to get to know WPF really well.
Its not a good question but WPF applications are is built on XAML. I started learning from WPFTUTORIAL
You will find that you will are likely to learn both at the same time. That said, XAML is a designed to be a mark-up language and is used for several technologies, e.g. WPF and WCF et. al.
As #bitbonk mentions, several books on the subject first give you an introduction to WPF (Dependency Objects, Visual Tree and Logical Tree, Controls, etc) before showing any XAML markup.
Whatever you do make sure that your first 2 or 3 applications are throw away apps (not production code). I have seen way too many developers code themselves into a hole when learning to code with WPF. I would recommend studying the MVVM pattern as well. This is critical to building stable WPF applications.
Here are some blog posts I have written that may be of some assistance.
http://tsells.wordpress.com/category/mvvm/
I've spent some time working on WinForm user and custom controls. However, in the back of my mind are the increasingly loud voices saying that WinForm technology is obsolete, and that WPF is the future on the desktop.
I've only looked superficially at WPF. Can anyone comment about if WinForm user controls can be used at all on WPF, and how different WinForm user controls are from WPF user controls?
Most of the controls I'm working on do some type of owner-draw as opposed to child controls being dropped onto the control. I'm just wondering how much of this code will be reusable under WPF.
It is certainly possible to use WinForms controls in a WPF application using the WindowsFormHost control. As usual, there are a few caveats. In particular, the two control types don't overlap well.
However, doing so seems that it would prevent you from taking advantage of many (if not nearly all) of the benefits of switching to WPF in the first place. If you have a large code base that's working for you, I'm not sure why you feel you need to migrate. There will always be something newer that comes along. The real battle is figuring out whether it's really better, at least for your particular situation.
Mandatory disclaimer: I'm far from an expert on WPF and apparently quite a bit less jaded on WinForms than many developers are. So perhaps my advice should be taken with a grain of salt, but I think it's worth considering nevertheless.
Your controls will be reusable (through WindowsFormHost, as Cody suggested). However, I'd not bank on being able to port your code across to WPF. The fundamental programming model is quite different (WPF relies heavily on data binding and thus benefits from very different code-behind), as is the rendering model (WPF doesn't use GDI+). The best way to approach most controls in WPF is to use the built-in templating; other than custom layout panels (which isn't really "drawing"), I've found nothing so far that requires custom draw methods in controls.
It'd certainly be a waste to create a WPF application just to host your WinForms controls. WPF may (or may not!) be "the future" but that doesn't mean you should throw away what you've got on a whim.
You say you've only looked superficially. If you think it might be worth investment, why not do an R&D project to prove how the integration might work on a small part of the system?
Which library to use for WPF?
Infragistics
ComponentOne
SyncFusions
ActiProSoftware
Telerik
#Reed - None of the Syncfusion WPF controls were ported from Windows Forms. With the grid control, most vendors use a simple ItemsControl based architecture. We have a much more elaborate infrastructure for highly optimized cell oriented rendering. This was implemented to achieve performance as close to Windows Forms performance as possible. The effort on our end to deliver this solution when contrasted with a pure ItemsControl based approach was at least 5x. We have a lot of customers using our Windows Forms controls in real-time scenarios and we wanted to give them the ability to move over to WPF without losing on the performance front. Our key controls offer excellent rendering performance even with millions of data points in direct contrast to solutions that are based on a simple ItemsControl based approach. Our controls often have a steeper adoption curve than others but in the long term we do believe that they are easier to maintain and update. Just my two cents:) Also, we are really keen to work with you on any issues that you are running into. Please let us know. My email is danielj(at)syncfusion.com.
#Tom - If you can send us feedback on the gauge we would greatly appreciate it. We are always looking for ways to improve and your feedback will be really useful.
Ultimately it depends on what you need. I think Syncfusion offers the widest and most actively deployed control suite on the WPF front. Disclaimer - I work for Syncfusion.
I work for a large firm which has long-term license agreement with Syncfusion so I had to use their products for years in pain.
I agree with Reed for Syncfusion's model. They converted their Winforms model (which has major bugs) to look it like WPF, I believe the whole suite is nothing to do with WPF, most of their controls cannot be controlled in XAML, you need to use code behind in order to style even simple things.
They are actually improving this to look more like WPF however with Syncfusion one issue is when you upgrade to a new version, it always breaks previous version based code. It is their marketing strategy and you spend weeks to figure out the new system.
One other issue with Syncfusion is they have quite poor documentation, their support is very weak, so you need to discover things on your own.
I used Telerik WPF in one project which is a much better choice, the performance is much better and the model is really easy to maintain.
We just started to buy DevExpress due to the pain of Syncfusion over years and I believe this is quite good WPF product. It is easy to use, they have really good support and nice documentation. The controls look very professional. First time I feel like I am using actual commercial .NET toolset.
*I do not work for DevExpress or Telerik.
They all have advantages and disadvantages.
Personally, I've found Telerik and Infragistics seemed more like they were designed specifically with WPF in mind.
Syncfusion's offering is more of a port of their Windows Forms product, so the design is more like they're other product lines.
That being said, each product you listed is good - and each have their own feature set. There is no substitute for trying a demo and seeing how you like working with the products in question.
I'm a fan of Component One, mainly based on personal taste.
ActiProSoftware have some good controls, but I find that they don't expose enough properties to make it easy to style and customize, though you can get around this with implicit styles.
Xceed have my favourite Grid control, lots of cool features and easy to work with.
I don't particularly like Telerik and I've never tried SyncFusion.
I would love to try Infragistics as that is one that I haven't tried, but have been really impressed with the demos. Does anyone have any comments on the architecture of Infragistics?
Like Reed said, they all have their advantages and disadvantages, but from my experiences I would recommend Component One.
HTH
None of the above, just use WPF Toolkit for DataGrid and VisualStateManager. It is not that hard to style the controls in WPF/Blend, plus it makes YOU more proficient and your code leaner.
P.S. Though, you might still use third-party reporting, since there no built in support for reporting in WPF.
If you are looking for a WPF Control Library there is the WpfDynamicUI Library.
It is an open source control building the user interface for the DataContext you provide.
It supports Charting, DataGrid, Map, Filtering, Paging, Nesting views and more...
Can be an alternative for building Line Of Business application.
PS: I am the coordinator of WpfDynamicUI
Well we are considering to move from WinForms to WPF, what pitfalls does WPF have? And we got component one's flexgrid is there any wpf grid that has the same functions? one nice thing with it is that you can implement your own draw method for the cells... It can merge cells print and save to many file formats..
In general, WPF development is very different from WinForms. You should expect it will take some time to learn the new technology (or you might even need to hire new developers =)).
WPF approach is in many ways better than WinForms' one: check out styles and triggers, data binding, control templating, eventing model.
I would recommend you to start exploring it, but wait for the WPF 4 (and the boring MSDN page) to start the actual migration, because it is going to be even better and close some of the very annoying gaps.
First of all, WPF works pretty different from Windows Forms and likely requires a different approach on how to structure and design the application. At least it works way better if you do it the way it was conceived.
As for single Windows Forms controls, this shouldn't be a problem. There is a WindowsFormsHost which enables you to include Windows Forms controls in WPF.
The change from winforms to WPF is not a change I'd reccommend unless you have specific requirements which WPF fulfills - WPF is not intended to be a replacement, simply an alternative which is more suited towards graphically rich applications.
If you do have a specific requirement then you also might want to consider embedding WPF controls into winforms applications, rather than converting your entire application.
The learning curve is slow to get going, but once you get the idea it all starts to make sense. We have "Pro WPF in C# 2008" book floating round the office and its been a great help. Of course most things get googled to find an answer, but to find out why something is done the way it is this book was a great hope - to me anyway.
There are some annoying features but its still WPF is still quite new. Like most things, if you come across a problem someone has likely come across it before and there is an answer out there!!
J
Take a look here for a datagrid: http://wpf.codeplex.com/Release/ProjectReleases.aspx?ReleaseId=29117
The main hurdle with WPF is simply the huge amount of new stuff to learn (if you wish to use it properly). I'd think twice if you're on a tight schedule, but it might be worth it if you have 6 months to spare...
Speaking from just my experience, moving from Windows Forms to WPF took some re-learning. A few months into the transition most changes made total sense. WPF removes much of the frustration associated with using Windows Forms. It allows for a truly rich UI development experience especially when working in tandem with designers. I strongly recommend WPF Illustrated by Daniel Solis as a learning aid.
With reference to the grid, Syncfusion offers a WPF grid control that implements the features you have asked for. It implements true virtual mode with cell level customization, printing and export to multiple formats including Excel. Disclaimer - I work for Syncfusion.