Listening to a dependency property changes in Universal Windows App in C++

If you want to be notified when some dependency property of a control changes, for example, UIElement::Visibility, you can do the following trick. First declare you own dependency property of the same type in some class:

public ref class MyListener

    static property Windows::UI::Xaml::DependencyProperty ^ BoundVisibilityProperty
        Windows::UI::Xaml::DependencyProperty ^ get() { return boundVisibilityProperty; }

    property Windows::UI::Xaml::Visibility BoundVisibility
        Windows::UI::Xaml::Visibility get() { return safe_cast<Windows::UI::Xaml::Visibility>(GetValue(boundVisibilityProperty)); }
        void set(Windows::UI::Xaml::Visibility value) { SetValue(boundVisibilityProperty, value); }

    static Windows::UI::Xaml::DependencyProperty ^ boundVisibilityProperty;

    static void OnBoundVisibilityChanged(DependencyObject^ d, Windows::UI::Xaml::DependencyPropertyChangedEventArgs^ e);


Drawing 2D vector Nautical Charts with OpenGL ES 2.0/3.2

In this article, I will show how the basic OpenGL ES 2.0/3.2 techniques, allowing to utilize the power of modern GPUs, can be used to draw 2D vector nautical charts by the example of S57 format. And as you probably already have guessed, the first technique I am going to consider is using vertex buffers for storing objects that makes up the chart. I will say at once that it is not a trivial task because, for example, some area in S57 chart can be filled and outlined with specific patterns generated from so called Presentation Library and at that, the fill pattern should be aligned to the left-top corner of the screen, but not to the area itself, so when the user shift the chart, the fill pattern does not move. The other example is a point objects or symbol that should be shown in the center of the visible part of an area, so its geographical coordinates changes when the user offsets or scales the chart. Theoretically, if we have OpenGL ES 3.2, we can use geometry shaders for drawing patterns, but if we have only OpenGL ES 2.0 that does not support geometry shaders, those patterns can also be drawn with the vertex buffers that should be regenerated each time the user changes the scale. So let’s start to solve this complex task with a simple example when we have geographic area or polygon filled with blue color, at least this example will demonstrate the basic idea of using the vertex buffers.


Developing Universal Windows App (UWP) with Xamarin.Forms 2.0 in Visual Studio 2015

Visual Studio 2015 has “Blank App (Xamarin.Forms Portable)” project template that creates three separate C# projects for Android, iOS and Windows.Phone 8.0 platforms that share the same C#/XAML code via so called PCL (Portable Class Library):

Blank App (Xamarin.Forms Portable)


Initialization of UWP C++ XAML application

UWP C++ applications based on “DirectX 11 and XAML App” or “XAML App for OpenGL ES“ project templates have some partial App class defined in user code and in generated file App.g.h:

partial ref class App :  public ::Windows::UI::Xaml::Application,
    public ::Windows::UI::Xaml::Markup::IXamlMetadataProvider
    void InitializeComponent();
    virtual ::Windows::UI::Xaml::Markup::IXamlType^ GetXamlType(::Windows::UI::Xaml::Interop::TypeName type);
    virtual ::Windows::UI::Xaml::Markup::IXamlType^ GetXamlType(::Platform::String^ fullName);
    virtual ::Platform::Array<::Windows::UI::Xaml::Markup::XmlnsDefinition>^ GetXmlnsDefinitions();
    ::XamlTypeInfo::InfoProvider::XamlTypeInfoProvider^ _provider;
    bool _contentLoaded;

the user code:

ref class App sealed
    virtual void OnLaunched(Windows::ApplicationModel::Activation::LaunchActivatedEventArgs^ e) override;


Creating cross platform (Android, iOS, UWP) OpenGLES 2 applications with VS2015

Cross platform (Android, iOS, UWP) OpenGLES 2 application can be easily created in VS2015 using “OpenGLES 2 Application (Android, iOS, Windows Universal)” project template:

“OpenGLES 2 Application (Android, iOS, Windows Universal)” project template


Building GDAL with Visual Studio 2013 and 2015

Unfortunately, GDAL 2.0.1 does not build with VS2015. I tried to build it with the following command from Command Prompt:

nmake /f

having gdal-2.0.1 as the current directory. Build has taken some significant time, but finally got some liker error “odbccp32.lib(dllload.obj) : error LNK2019: unresolved external symbol __vsnwprintf_s referenced in function”:

building GDAL with VS2015


Combining OpenGL and XAML together in a Universal Windows App (UWP)

Visual Studio 2015 allows easily combine OpenGL graphics with XAML controls in a single window. To accomplish this task we can create a new project based on “XAML App for OpenGL ES (Universal Windows)” template:

XAML App for OpenGL ES (Universal Windows)


Compiling MSOpenTech ANGLE project

ANGLE is a wrapper library that implements OpenGL ES API (version 2.0 and parts of 3.0) and translates OpenGL ES calls to their DirectX equivalents. See for more information.

There are two options how to use ANGLE: install its binaries as a NuGet package or compile it from the source code. I believe that cool software developers, like real heroes, never search easy ways, so I decided to compile ANGLE from the source code with VS2015 Community.

First I cloned the repository and ensured that my branch is ms-master:

ANGLE project in VS2015ANGLE project in VS2015


Synchronization mechanism in DirectX 11 and XAML UWP application

Probably it would be better if I learned Java 15 years ago because Java technologies do not change so rapidly, but I love C++ very much and I spent some time investigating how the application based on DirectX 11 and XAML Visual Studio 2015 template works on relatively new UWP platform.


In opposite to Win32, there are no main thread in UWP applications, because in UWP application each top-level window runs on its own thread. Our application has only one top-level window so it has one UI thread and also it has event handling thread and renderer thread (creating new top-level window will require some adaptive changes in our application).


Limitations of WinRT platform

WinRT has a huge amount of new functionality that makes it an exciting development platform and from GUI developer perspective it has a lot of significant benefits over WPF such as the ability to combine XAML and DirectX together and better managed and unmanaged code integration with new C++/CX compiler and COM based WinRT components. But from other side, WinRT has a number of limitations that developers who migrate their code from WPF to WinRT should be aware of. Below I briefly described those limitations.

COM based components limitations

WinRT components actually are not classes they are COM objects, so they can not be inherited and can only be used as a set of interfaces, that is why we use sealed keyword with the component class declaration in C# and C++. In my opinion this is significant disadvantage that breaks the object oriented paradigm.

The lack of synchronous methods in API

WinRT asynchronous API is useful when I have an button click handler that opens a file, for example. In this case async/await keywords help me to write a code that does not block UI thread. But what if I already have a separate non-UI thread that opens a file? Why should I use asynchronous API if my separate thread does not block anything?

The possible solution in this case is to use old C-style API like ::CreateFile2, for example.