Your website is horrible.
I spent an entire afternoon looking for information about how to add and retrieve data to/from a dropdown list control that should be intuitively available in close proximity to it's "Overview" page (after a lot of stumbling around I found where the "add" part was but the "retrieve" part was not found. I finally gave up and pinged Support. Another day is lost.).
And this isn't the first time I spent several hours searching for fundamental class information such as that which would be locatable in a traversable complete class hierarchy. I couldn't even find signatures to constructors for basic components such as RadProperty.
I hate to say it but your website is approaching the near-uselessness that plagues MSDN.
The difference is that I'm paying a truckload of money for the Telerik library. I dread using new controls for your product because I know what an exercise in rage it's going to be figuring out how it works. You laugh, I know. I understand. But it's the truth. I need to wear a mouth guard or pop some Xanax every time I come here. BTW, can I get a refund?
If not, please rewrite your website with your clientele in mind. Assume they know nothing that you know about your product.
My suggested solution is to use a visual model such as is demonstrated at: https://docs.telerik.com/devtools/winforms/telerik-presentation-framework/class-hierarchy/class-hierarchy-overview.html.
You could even start out with a scrolling 400 square-foot wall chart. I wouldn't care if it took a half-hour to download. I'd still be saving time.
And that's both my feedback and feature request that'll wind up in the digital dumpster.
Jay
Clearly you are frustrated and I'm sorry to see using our products is causing that. I have to say that my team and I take this very seriously and do not find it funny one bit.
I certainly understand the difficulties of learning a new development library or, in fact, any new software. Allow me to try and address the concrete questions you've brought up and I'll follow-up with a short explanation of our documentation organization that I hope will help.
----------
RadProperty Contructors
The reason why you cannot find information for RadProperty constructor signatures is because there isn't a public constructor intended for usage by the developer. Here's a portion of the decompiled class for a reference:
The RadProperty conceptual topic details on the common usage of defining such object.
----------
RadDropDownList
I'm looking at your question about RadDropDownList and the support ticket where you are discussing this with Dess but I'm having a hard time understanding what you are trying to achieve. I believe you may be trying to manipulate the Items collection, in which case the following two topics might be useful:
- Adding items programmatically
- Selection and in particular the SelectedItem/SelectedIndex members
If neither of this helps, I'd encourage you to explain the end goal you are trying to achieve in the support ticket and one of our support engineers will help you out.
----------
Documentation Organization
Which brings me to the next topic of how our documentation is organized. In short, we try to expose information in two types of articles - one is the API reference content and the other is conceptual, very commonly how-to focused.
My personal recommendation would be to try solving issues as they come using the conceptual topics and/or knowledge base articles. Our products have countless possible usages since they are built with extensibility in mind, but we also constantly work on adding new articles that address scenarios. I'll be first to admit that our docs are not perfect, however I have to say we are very receptive to constructive criticism and always happy to address suggestions that make sense for our user base.
That said, I have to mention that the MSDN documentation is pointed by our customer base as a good example, so I'm a bit surprised to hear you do not find it useful. Furthermore, most of our customers are in fact reporting a need for content oriented towards scenarios such as how to manipulate the Items collection of a drop-down list and code examples.
From that perspective, I think an enormous class hierarchy on our website that lists each member will be neither easy to navigate, nor practical. We are after all talking about a library of 130+ controls residing in several assemblies.
----------
My Suggestion to You
The information I've shared concerns how we see users most commonly consuming content, however I also fully understand people are different and have different needs.
Based on your feedback and after reviewing your previous communication with my team, I have a suggestion. It seems to me you would prefer to understand in depth the way the components are built and are functioning. I may be totally off here, but in case my assumption is correct, you could consider downloading the complete suite source code from your Telerik account: Telerik UI for WinForms Downloads.
We distribute the code for educational purposes and it comes handy in scenarios when you are wondering how does a specific class/method function. Alternatively, a decompiling engine like our JustDecompile product might be handy as well (this is what I used to quickly check the RadProperty constructor above).
----------
Feature Request
I may be totally wrong and other customers could indeed be in need for a visual representation of our API. I'm more than happy to leave a feature request on this portal in which we can gauge the user interest. My concern is you and I have discussed several topics in here and the title of this item is a bit generic. I suggest separating the concrete idea in a new item and can do that for you if you are okay with it.
Finally, I'm available to further discuss any concerns or questions related to documentation, support and your overall experience. You can reach me here, through a support ticket or directly at petya.sotirova[at]progress.com
Regards,
Petya Sotirova
Technical Support Manager, Sr.
Progress Telerik