This is a migrated thread and some comments may be shown as answers.

Some thoughts and disappointments

4 Answers 242 Views

General Discussions

This is a migrated thread and some comments may be shown as answers.

Alex Peachey asked on 16 Mar 2009, 10:33 PM

I've been using various Telerik controls for a few years now. I've used the ASP.Net/Ajax controls, the WinForms Controls, the Reporting library, and now as my latest application is based on WPF, I've been trying out some of the WPF controls. I've been fairly happy with Telerik controls in the past on other platforms with minor exceptions here and there.

Using the WPF controls though, I find myself getting frustrated and not finding much use for them. I know WPF is still young, but somethings I'm running into that I would expect better results on are listed below.

1. The documentation is poor. Compared to other control sets here at Telerik, I often find myself unable to find how to do something other than by trial and error. The documentation samples are minimal and features are given very cursory overviews. Usually I end up having to just plop a control in my xaml and start playing with intellisense options to figure out anything.

2. DataBinding in WPF is much more powerful than in WinForms. However, it appears in many cases when building up the controls, Telerik had a very WinForms centric view. I've run into numerous occations where I have tried to bind a property only to be told I can't bind it because it's not a Dependancy Property. Unless there are very good reasons, I would expect most any property on a control to be a bindable dependancy property.

3. DataGrid - I see little reason to use the DataGrid instead of the DataGrid in the WPF Toolkit. The DataGrids in the other products are very rich and provide many reasons to use them over the stock Grid. Using the Telerik DataGrid in WPF it almost feels crippled when I can't help but compare it to the other products. Filtering is probably the biggest downside on this one. I know I can add in some custom filtering as per some of the examples, but in my opinion filtering should be the same across all platforms you offer. I had an idea on how I could restyle the header and include my own filter controls similar to the other products, but again, refering to number 2 above, I ran into some things I couldn't bind to. I'd also like to see not just for the DataGrid, but especially for the DataGrid a more "plain" theme choice.

4. Chart - The chart control has some severe limitations. The biggest being the inability to use strings as values. Probably the most basic chart is either a column or pie chart. In a column chart, the most common use is to show for a series of categories, different values. In almost all instances the categories are either strings or dates. By not allowing string values, it makes it hard/impossible to show a very basic chart. There is another post on this issue where it's described how in code behind you can reset the tick labels after binding or some such thing but that is a very smelly solution. In general the chart is not very friendly for declarative structure and binding. I should be able to describe in XAML how it should work and bind it to a collection and get the chart I want. Almost all examples show everything driven in code behind and I believe the reason is the xaml is either convoluted or in many cases not even possible. One of your examples is an MVVM example and I laughed when I saw it as it wasn't MVVM at all. You had a XAML file with a few bindings and a slew of code behind interacting with the GUI. The project I am working on is entirely MVVM and I have yet to find a reason to put code in the code-behind of a XAML file. There are always the exceptions where the code is truely just for the GUI and it makes sense and I'll likely have a small bit of codebehind when the project is finished but in general everything should be declarative and code/logic kept separate in the viewmodel. In the end, for now I'm using another company's chart control as it allows better MVVM support as well as string values.

5. Other controls - I haven't gotten to using any of the other controls yet as most seemed derivative of the standard controls with not much value add. It might in some cases save a bit of customizing the standard controls, but I have a feeling after using the controls I have used, I'd run into more issues/customizing than it would save.

In closing, I am still a fan of Telerik but can only really recommend their more mature toolkits. I was hoping for a lot more changes in 2009Q1 as I felt there had been enough time since the first WPF drops to mature the product.

4 Answers, 1 is accepted

answered on 17 Mar 2009, 04:21 PM

Hello,

1. You are definitely right. Currently our documentation is far from desired stage however I can assure you that we are working hard to improve this - in the meantime you can ask (or suggest) anything in our forums.

2. Please provide complete list with such properties and we will fix them immediately! I've reviewed your support history and I notice that you have only one forum post related to our WPF controls - please provide more info.

3. Here are top five reasons:
   - RadGridView is more than four times faster - you can check this demo and try to replicate the same with MS DataGrid:
     http://demos.telerik.com/wpf/?GridView/Performance/ClientSide

   - In RadGridView you have built-in UI for filtering, grouping, column freezing, etc. - no such thing in MS DataGrid

   - RadGridView can work with your collection of objects - in MS DataGrid you cannot sort, filter or group custom collection of objects without CollectionView

   - RadGridView API (and code) is shared between Silveright and WPF versions - currently we have two different grids for SL and WPF from MS.

    - Advanced hierarchy model:
      http://demos.telerik.com/wpf/?GridView/FirstLook

As for the filtering I believe that current grid filter is a bit more advanced than previous:

4. Onto your charting remarks:

RadChart does support string values as axis item labels -- as you correctly noted you can achieve this functionality by manually configuring the axis TickPoint values in code-behind. It is true, however, that the current version of the control does not support automatic axis databinding and we plan to address this limitation for the Q2 2009 release later this year.
As for the declarative chart -- you can find the "Declarative Chart" example in the RadChart QuickStart examples that demonstrates it is possible to initialize and visualize the control entirely from XAML.
As for the MVVM example -- we will not go into discussions what MVVM is, or is not -- this example demonstrates one possible scenario achieved via re-templating and custom ViewModel (that calculates the bar color based on the grades from the data) much like the one described here for the Silverlight Toolkit charting component.

5. Please share your feedback about other controls and don't hesitate to contact us if you have any problems and/or questions.

Greetings,
Vlad
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Check out the tips for optimizing your support resource searches.

answered on 17 Mar 2009, 05:58 PM

Thank you for your response as it does look like you are thinking about or addressing some things. It would be nice though to have more of a roadmap so we can all tell where Telerik is headed and what your views on certain aspects of WPF are. I don't even need to know what release something might be in, just that you have it on a list of things you plan on changing.

To re-address your points, answer questions posed, and make additional comments:

1. I'm glad to hear you are working on the documentation. I figured/hoped you were, but hearing it is in progress is good. I will ask questions on the forum as needed, it can just get frustrating though to be in the middle of putting a module together and get stuck and have to put it aside and out of mind and work on something else until an answer is available.

2. The prime example on unbindable properties would be the FilterDescription on a Grid. We can evidently make our own custom FilterDescriptions to over come the limited filtering built in, but the only way it appears you can set this is via code behind. Not being able to bind something like this makes custom filtering clunky. Another example would be in the Chart, speaking to the strings on the x-axis. There is a hack solution to do this via setting the tickpoint values in code behind. But yet there doesn't appear to be a way to do this via XAML. The individual examples don't matter too much though as my point is more systemic. It really looks and feels like the Telerik team views WPF as a slicker looking version of WinForms. The platforms are quite different and WPF is much more powerful as far as control over presentation and seperation of GUI from Code/Logic. Yet practically every example in the WPF section shows how to do something by setting values or manipulating things in code behind. Anything you can set or do in code behind should theoretically be possible to express in XAML. If it's not, the control is not very WPF friendly. As an experiment, I'd love to see your team take all of your examples, build them entirely in XAML, and then just set bindings to access whatever data is needed. I think in the process you'd see all of the places where we are limited.

3. I do admit there are definitely some features the Telerik Grid has that the MS Grid does not. The most noteable and useful is the Grouping. The filtering is only a so-so feature. It may be great for people who are starting from scratch on a new project and have never used a control from WinForms or ASP.Net. However, if I were to release a program using this WPF Grid my users would be frustrated that they can't filter and control the data as they can in other tools. I'm just saying that if you are going to have a comparable product on multiple platforms they should in general act the same. As I mentioned, I think I have come up with a way to use a custom header template to allow similar functionality as previous grids, but in order to make it work I need to be able to bind to the FilterDescription.

4. I'm glad to hear you plan on fixing the string issue in Q2. Considering the number of charts that require this feature it is greatly needed. I have yet to run into a business chart that just had "1 2 3 4 5 6 7 8 9 10" running along the x-axis with columns of data rising up and no indication of what in the world it means to have 42 of "5". As to the declarative version of the chart, that turns out to be more a combination of documentation and the string issue. I at first couldn't figure out how to do series mappings in XAML, but I have that figured out now but since I couldn't use strings, I had to use something else.

4b. As to MVVM. I find it disheartening that your response is you don't want to discuss what is or is not MVVM. As just about anyone working with WPF at Microsoft and other industry leaders can attest, WPF and MVVM are becoming more synomous as the WPF structure just "fits" MVVM so naturally. So as a toolkit provider for WPF, I feel it is imperative that Telerik have a modern view of both WPF and MVVM methodology. A company like Telerik should be a true partner to the developers using their tools and that means understanding how the developers are using the tools. This also means common understandings of what certain paterns and methodologies mean.

My bottomline: What I am looking for and expect from the WPF controls is to be able to:
1. Layout/style/describe everything about the control in XAML.
2. Bind any individual property to a property on the datasource.
3. Bind any collection or series of properties to a collection on the datasource.
4. Have examples and solutions to questions that do not rely on codebehind to fix the issue.
5. And of course documentation.

I know Telerik is a very responsive company. The team members always have been in the past and continue to be. I think the WPF controls have a lot of potential, but as a solution are still unpolished. I'll continue to watch what is happening with the tools and perhaps by the Q2 or Q3 release I might be able to start integrating more of them in my projects.

I hope you don't feel like my original message or this one is an attack on you. It's merely a declaration of disappointment as I, and I think many others had higher hopes for 2009 Q1. We developers like new toys and look forward to each of your releases with great anticipation that both our previous issues have been resolved and new functionality has been added. As Trimox said though, this release felt more like a simple maintenance release and even at that many issues were still left unresolved.