We have received several requests so far by customers who one way or another ask for the same thing: "Can you make your WPF controls in such a way that later when I convert my WinForms application (which use your WinForms controls) to WPF I wouldn't need to deal with different APIs and inconsistencies?".
In general, this could be achieved if we had:
The first point is feasible and we'll do our best to do it.
The second, however, is something we probably won’t do. Believe us, you wouldn't want us to give you a set of WPF controls having the same API as our WinForms controls, just for the sake of conversion. It's not that the API of our WinForms controls is not good - quite the opposite. It's because WPF and WinForms are too different. The main difference is in the UI which in WinForms is customizable through the API, while in WPF the best place to put your UI customizations in is the XAML. In WPF we also have some new concepts like dependency properties, attached properties, routed events, templates, styles, triggers, etc. which could change a lot the way you achieve certain things in WPF.
Of course, it always depends on what you'd like to accomplish. In case you want to extend your WinForms application and add a little bit of WPF flavor in it, but you still don't want to rewrite your whole application, then most probably you don't need a conversion. The better route will be to host WinForms controls in WPF, or have WPF elements in WinForms.
In case you’d want your WinForms application to become a 100% WPF application, then you should be ready to spent some time converting not only the code which uses 3rd party WinForms controls (e.g. ours), but also the rest of the code which doesn't deal with controls. My personal recommendation is that you throw away most (or better all) of the code dealing with UI in your WinForms application and do it the WPF way in your WPF application.
But are there any good news? Yes. The first good news is that RadControls for WinForms enforce a strict separation between UI customizations and business logic through the built-in theming mechanism (the themes built with our Visual Style Builder are serialized as xml files). That spares you the trouble of reviewing all your code and porting UI-related stuff to XAML while keeping business logic intact.
The other good news is that we've already adopted some of the WPF paradigms in our WinForms controls: we're using commands, a similar dependency property mechanism and routed events. If you're already using them chances are that you'd have an easier conversion on WPF once you start doing it.