Two weeks ago we released a public BETA of the world’s first commercial library for building Windows 8 Metro applications – Telerik RadControls for Metro. So far we have gathered lots of positive feedback as well as some specific questions regarding our XAML components. Such an interesting question is whether our controls can be used in a C++ application.
Prior to WinRT (Windows Runtime), the XAML platform was available to managed developers only and we, at Telerik, have solid technical background with C# and .NET. That’s why we have built our Metro XAML components using C# and the .NET runtime. We performed very thorough tests and comparisons between C++/XAML and C#/XAML and the tests showed that while C++ performs better than C# in most of the areas, the differences can be considered insignificant for most of the general-purpose scenarios. Additionally, WinRT makes it possible to integrate immediate mode rendering (using Direct2D APIs) directly on the XAML surface, which enables us to have performance-critical sections rendered using D2D plus some algorithms implemented in C++ for better performance.
Back to the question – can our controls be consumed from C++? The answer is: not directly, but there is a very simple trick that you can use to run them from a C++ application:
What you need to do is the following:
[Download the demo project]
Probably you are wondering why we haven’t implemented our C# components as Windows Runtime Components, making them natively consumable from either C++ or C#. The answer is simple: the “Everything is sealed” restriction of WindowsRuntimeComponent class library type prevents us from having the architecture and class hierarchy that we would like to. Here is a quick example:
We have the following hierarchy in our charting component:
RadControl -> ChartElementPresenter -> RadChartBase -> RadCartesianChart
Such a hierarchy cannot be achieved for third-party WinRT components (only Microsoft can do it). Our only option would be to have one Uber type – RadChart – and to use “aggregation and delegation”, that is to have different “Impl” objects, aggregated by the control, and handling specific functionality. Hence we built our components as standard class libraries, meaning you cannot add references to them directly from C++ but to use the above trick and an intermediate assembly that translates the desired UI to C++.
Using the above described approach to load the Telerik components implies that you will have the .NET Runtime loaded within your C++ application. This adds some additional overhead but as I already mentioned, this overhead can be considered insignificant for the start-up time of the application.
I hope that you will find this post helpful. Please let us know whether you – the C++ developer – accept this approach and would you be willing to use, let's say Telerik RadChart, in your application.