I was working on transforming a Windows Store app into an Universal app so that it worked not just for Windows Store but also for Windows Phone. When you do this two new projects are added to the solution. One of them is a special one, called shared project that you can use to keep files shared between platforms.

universalapp1

universalapp2

In my case, one of those shared files were the App.xaml and App.xaml.cs. So what I did was moving these files from the original Windows Store app to the shared folder and then delete the copies from each platform specific project.

universalapp3

When I did this however, I run into several problems.

C:\Program Files (x86)\MSBuild\Microsoft\WindowsXaml\v12.0\8.1\Microsoft.Windows.UI.Xaml.Common.targets(327,9): Xaml Internal Error error WMC9999: Object reference not set to an instance of an object.

This was fixable by rebuilding the project. However, a new error appeared:

CSC : error CS5001: Program ‘c:\Work\Demos\DemoApp\obj\Debug\intermediatexaml\DemoApp.exe’ does not contain a static ‘Main’ method suitable for an entry point

Everything looked good, but whatever I tried the error still persisted. Eventually, I figured it out that the build action for the App.xaml file was wrong. When the files where included in the project, App.xaml was added as a simple Page.

universalapp4

However, this is not a regular page, it’s an application definition and the build action must be manually changed accordingly.

universalapp5

When you make this change and rebuild again (a simple build won’t suffice) everything works fine again.

, , , , , Hits for this post: 21666 .

In WPF, Silverlight and Windows Phone it is possible to render a visual object into a bitmap using the RenderTargetBitmap. This functionality, that I find pretty basic, was not available for Windows Store applications. Fortunately, Windows 8.1 provides that functionality for Windows Store applications too, through the same RenderTargetBitmap class.

There are some limitations though:

  • it should be used in the code behind (not declared in XAML) because you have to call RenderAsync
  • collapsed visual objects are not rendered (only visible ones)
  • in rare circumstances the content can be lost due to the interaction with lower level systems; in this case a specific exception is triggered
  • the rendered target bitmap does not automatically scale when the current DPI settings change
  • the maximum rendered size of a XAML visual tree is restricted by the maximum dimensions of a DirectX texture

Here is a demo Windows Store application that has several controls and a button that when pressed a screenshot of the area shown in red (it’s a grid) is taken. The bitmap is saved on disk, but also displayed as the source for the image control shown in the preview area.

wsas1

The handler for the Click button even looks like this:

SaveScreenshotAsync is an async method that takes the reference to the FrameworkElement to be rendered to a bitmap (in this case the constrolsGrid) and returns a Task<RenderedTargetBitmap> that can be awaited on. As soon as we have the bitmap we set it as the source for the image control (imagePreview).

wsas2

SaveScreenshotAsync is an async method that takes the FrameworkElement to be rendered to a bitmap and returns a Task<RenderedTargetBitmap> that can be awaited on. This method first prompts the user to select a destination file for the rendered bitmap. When the file is available it calls SaveToFileAsync to rendered the bitmap and write it to the file.

SaveToFileAsync is an async method that takes the FrameworkElement to be rendered to a bitmap and the StorageFile when the bitmap is to be saved and returns a Task<RenderedTargetBitmap> that can be awaited on. The file is opened asynchronous for read-write access and the returned IRandomAccessStream is passed further together with the framework element and the bitmap encoder id (that specifies how the bitmap should be encoded, i.e. BMP, JPEG, PNG, GIF, etc.) to CaptureToStreamAsync.

CaptureToStreamAsync creates a new RenderTargetBitmap object and calls RenderAsync to render the visual tree of the framework element to a bitmap. After the bitmap is rendered it retries the image as a buffer of byes in the BGRA8 format. It then asynchronously creates a BitmapEncoder for the IRandomAccessStream stream that it received as an argument, it calls SetPixelData to set the pixels data (notice the BitmapPixelFormat.Bgra8 parameter that matches the pixels format returned by GetPixelsAsync) and later asynchronously flushes all the image data, basically writing it to the file. It then returns that RenderTargetBitmap object that it created, which is used eventually as the source for the image control.

Here is how the saved JPEG image (also seen in the preview screenshot above) looks likes:
wsas3

You can check the source code of the attached WinRT Screenshot demo (1626). It requires Visual Studio 2013 and Windows 8.1.

, , , , , , Hits for this post: 42661 .

Partial classes are finally available to C++. Sort of. It’s not part of the new C++11 standard, it’s part of the C++/CX language developed by Microsoft for targeting WinRT on Windows 8.

Partial classes mean that you can define a class spanned across several files. Why is this great? Because it allows developers and automatic code generator tools (such as designers) to edit parts of the same class without interfering one with another. WinRT allows C++ developers to write UI in XAML. This could not have been possible without the support for partial classes.

Partial classes:

  • are available only for ref classes; native classes are not supported
  • are introduced with the partial keyword in all definitions but one

Here is an example:

What happens when you add a new page to a C++ Metro style application? The wizard generates three files: a XAML file and a header and cpp file as the code behind. Let’s say the page is called MainPage. In this case the three files are MainPage.xaml (code below is a dummy example), MainPage.xaml.h and MainPage.xaml.cpp.

You can notice that the objects firstPanel and firstButton are not defined in the header for MainPage and second, MainPage.xaml.h includes MainPage.g.h. So what is this? This is a designer generated file, which together with MainPage.g.cpp completes the definition of the MainPage ref class. These files are not generated until you start a build. After you do that you can find them in the output folder (Debug or Release for instance). This is how they look:

The following image illustrates the grouping of these files:

MainPage.xaml is a XAML files, which can be edited both by the designer or manually by the developer (basically with the designer is still the developer that models the UI). The other files are C++/CX files. MainPage.xaml.h and MainPage.xaml.cpp are the files the developer writes, while MainPage.g.h and MainPage.g.cpp are edited by the designer. Do not modify the code in these files, because you could either mess up the designer, or all your changes would get lost when the file is regenerated.

, , , , , , Hits for this post: 63016 .

When you create a WPF application, the start-up window is by default one from the same project (by default called Window1.xaml).

But what if you want to use a window from another project (class library)? The pack URI scheme, used by WPF, allows you to identify and load files from:

  • the current assembly
  • a referenced assembly
  • a location relative to an assembly
  • the site of origin for the application

The format of the pack URI is pack://authority/path. The authority identifies the type of package and the path the location of a part inside a package. There are two authorities supported by WPF:

  • application:/// identifies application data files (known at compile time)
  • siteoforigin:/// identifies site of origin files

To use resource files from a referenced assembly you need to use the application:/// authority, and the path must have the form AssemblyShortName[;Version][;PublicKey];component/Path. Version and PublicKey are optional.

Let’s say you want to use a XAML called SampleWindow.xaml from a referenced assembly called WpfDemoLib. The App.xaml file should look like this:

You can learn more about pack URIs in WPF from MSDN.

, , , , Hits for this post: 49388 .