Thank you very much for sharing your points. They are much appreciated.
Our main goals in building r.a.d.controls
are to reduce your development time, increase your productivity and help you "deliver more than expected" in terms of UI. Let me assure you that the new version of r.a.d.menu
(v4.0) has been developed only with our customers in mind and every single line of code we have written is intended to make things much easier for you.
Indeed we use the .NET mechanisms for providing deprecated and obsolete properties especially in our Service Packs and minor updates. However when introducing a completely new rewrite of a product these mechanisms do not prove very efficient.
Unfortunately, we are facing tough choices especially with new versions our "oldest" products (r.a.d.editor
, etc have been around for about 4 years now). When these controls were initially designed .NET programming was very different from today and if we want to stay at the top of the control vendors' offering we inevitably need to make big changes. One such change is introduced in the new version of r.a.d.menu
The previous architecture and design of the menu control had reached its limits and could not be extended any more without a serious hit on performance and efficiency. That is why we took the road of almost 100% code rewrite and launched the next generation of our r.a.d.menu
. We are very proud of the new semantic implementation which now renders with list items and thus tremendously reducing the HTML output by more than 70%. Except for the significantly improved footprint and performance r.a.d.menu
v4.0 now introduces powerful DataBinding capabilities, extended VS.NET Design-Time support, very easy to use single-property skinning mechanism, a variety of expand/collapse animation effects as well as an richer client-side API closely matching the server-side API. Needless to say these new improvements would not have been so impressive if we were to leave the old somewhat cumbersome logic and mark properties as deprecated or obsolete.
We are doing our best to prepare customers for the transition to the new version and have provided thorough migration guides with our documentation (Online Version
). We have also shipped an early beta version so that we could get as much feedback as possible and put it into production code. So far the general reaction from our customer base is very positive and all developers are excited to try the new version of r.a.d.menu
. (This same approach was used in our tab control rewrite last quarter and we are now seeing many happy customers of r.a.d.tabstrip
On behalf of the r.a.d.menu
team at t
elerik I do apologize for the time you will need to migrate your current projects to the new version but I believe that in the long term the new r.a.d.menu
will prove much better for everyone.
Once again I wish to thank you for the feedback and we will definitely have it in mind when we implement breaking changes across our product line.