Okay, we have already compiled our Windows Phone Chart under WinRT (refer to the previous post). The whole process went pretty straightforward and took less than an hour. Now, let’s move on with setting-up a demo project with a simple chart in it to verify the compilation and to check for some hidden exceptions. The steps are well familiar: File->New Project->Visual C#->Windows Metro Style->Application. Adding the reference to our freshly compiled chart and declaring it in XAML:
Running the project (fingers crossed), eager to see if everything is OK. Unfortunately no – we get our first exception:
Hmm, suspicious, everything looks properly set-up. Double-checking the XAML and the namespaces – they are fine. Starting the app again, hoping this was a sporadic :) exception. Well, the problem is still here and it is definitely not sporadic. Trying to find some hints about this in the internet but to no avail – WinRT is alive for literally several days and not much information is available. Fine, no problem – will create the chart in code and add it to the layout root.
Pressing F5 again to see what happens. Visual Studio now complains with another exception, this time displayed in a Message Box:
It is getting more and more interesting. What the f*** is going wrong now? Again, Internet doesn’t tell anything, revealing only several people fighting with the same problem. The other frustrating issue is that Visual Studio doesn’t break at the code line that triggers the underlying exception. Although we are handling the Application.Current.UnhandledException event the exception is not caught there. After some debugging it turned out that the exception is caused during the Application.Run call and probably by some unmanaged code.
Next step – removing all the theme files from Generic.xaml. Having in mind the previous exception with custom type resolution this failure may be due to the same problem. Bingo – the Run method is now successfully passed and we are breaking with a NullReferenceException due to the missing control template. The problem is isolated successfully, now thinking of a way to specify the control template. As a test, let’s put an empty Style instance, targeting RadCartesianChart, in the application resources, put a break point before the Run method and examine the Resources property in the debugger. The result is very impressive:
Point taken – no custom types in XAML in this early version of WinRT. Period. So far so good but how to display the chart actually? Trying code behind as our last resort:
Unfortunately the result is pretty much the same – COM exception with the “go figure” error code. What? We should wait for a more stable version of the framework to get the demo done? No way, let’s not give up and do our best in working-around this issue.
Actually this was the biggest challenge we faced while building the demo shown in the above video. After dozens of trial-error scenarios we successfully found the only possible solution. Creating a ControlTemplate targeting the base (well familiar to WinRT) Control type did the trick. Yes, sounds crazy but the chart was properly initialized with a visual tree and it took its first breath in this new world.
To sum up the pitfalls:
We believe that the above issues are either bugs or not implemented functionality in these early WinRT bits and they will not be present once a more mature version is out. Anyway, if you are experimenting for yourself it is good to know what to expect.
So, we have our charts in the demo created and initialized in code while the layout is done in XAML. There are many aspects of the application layout we consider interesting and which are worthy mentioning. A typical Metro app should support four different types of layout – FullScreen, Portrait, Filling and Snapped. This implies some more complex visual trees and event handling. But I will talk more about this stuff in my next posts to come, so make sure you do not miss them :)
Georgi has 15 years of experience in multiple software technologies. Ten years ago, he joined Telerik, later acquired by Progress, and he has set up and led multiple products and teams since. His latest endeavor is building a product that adds the Progress value into the augmented and virtual reality development workflow.
Subscribe to be the first to get our expert-written articles and tutorials for developers!