Creating chromeless, non-rectangular Windows from UWP


On my way back home from the IoT in Action event in Taipei I had a several hours time to work on a small personal spare-time app project that I am hoping to publish to the Store soon. One of my requirements involves a creating a secondary chromeless, non-rectangular utility window (that is also semi-transparent and topmost). UWP’s ApplicationView/Window doesn’t support chromeless, non-rectangular windows – but with the Windows application model being an à la carte platform, this can be accomplished by adding a desktop extension to my UWP app package that uses a WPF Window to provide the required rich windowing capabilities. My app/main window itself needs be UWP because of some other requirements.

I figured it would be useful to put together a quick sample and write-up for this, as I don’t believe we’ve ever had any docs/blogs/sample to date that describe how to create an arbitrarily shaped chromeless window from a UWP app. How arbitrary the shape can be you ask? Well, if you can draw it, it can be your window’s shape! To prove my claim my sample actually lets you hand-draw windows using the UWP InkCanvas control – check it out in the video:

In the secondary WPF windows you would typically host WPF controls to implement your UI – and now with XAML Islands (introduced in 1809) you could also host UWP controls. Note though that the XAML Island itself needs to be rectangular, if you decide to use one. In my sample app here I am just hosting a re-styled WPF button that serves as my close button. The sample app works on build 1709 and above (though the features used here are already available since build 1607). Read on for details on how to implement this scenario with just a couple of lines of code.


Just show me the code on GitHub and let me install the sample app from the Store …

Sample Source Code

Sample App Installer:


Source Code Walkthrough

Project Structure

The Visual Studio solution for this sample consists of three projects:

  1. The actual UWP main app (“Sketch-a-Window”)
  2. A WPF project that provides the windowing feature (“WPF”)
  3. A Windows App Packaging project to package the two together for distribution (“Package”)


Package Manifest

The appxmanifest file in the Package project is the one that is relevant at deployment time. Here we need to add the declaration for our desktop extension, so that the UWP app can activate the WPF process for creating the windows.

  <desktop:Extension Category="windows.fullTrustProcess" Executable="WPF\WPF.exe" />

UWP Code

The gist on the UWP side is that we are using the FullTrustProcessLauncher API to create the WPF window. To pass on the geometry details about the shape of the window we are using the local AppData settings. Most of the code here is specific to getting the geometry info from the collected ink stroke and passing it down to the WPF. You obviously won’t need all this code if you are creating windows of well-known shapes.

private async void InkPresenter_StrokesCollected(InkPresenter sender, InkStrokesCollectedEventArgs args)
    Rect viewBounds = ApplicationView.GetForCurrentView().VisibleBounds;
    Rect inkBounds = args.Strokes[0].BoundingRect;
    Rect winBounds = Window.Current.Bounds;
    ApplicationData.Current.LocalSettings.Values["X"] = viewBounds.X + inkBounds.Left;
    ApplicationData.Current.LocalSettings.Values["Y"] = viewBounds.Y + inkBounds.Top;
    ApplicationData.Current.LocalSettings.Values["Width"] = winBounds.Width;
    ApplicationData.Current.LocalSettings.Values["Height"] = winBounds.Height;
    var inkPoints = args.Strokes[0].GetInkPoints();
    var rawPoints = new double[inkPoints.Count * 2];
    for(int i=0; i<inkPoints.Count; i++)
        rawPoints[2 * i]     = inkPoints[i].Position.X - inkBounds.Left;
        rawPoints[2 * i + 1] = inkPoints[i].Position.Y - inkBounds.Top;

    if (ApiInformation.IsApiContractPresent("Windows.ApplicationModel.FullTrustAppContract", 1, 0))
        await FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();
    await Task.Delay(1000);

WPF Code

Now on the WPF side, we are creating a window with the desired rich capabilities, specifically in this case we want to allow transparency, remove the chrome and make it topmost, which can be declared in markup like this:

<Window x:Class="WPF.MainWindow"
        WindowStyle="None" Topmost="True" AllowsTransparency="True">

In the code-behind we need to unpack the geometry information about the ink stroke and clip the window accordingly. Again, most of the code here is specific to the sample dealing with complex shapes defined by ink strokes and you won’t need it when creating windows with well-known shapes:

public MainWindow()
    this.Left = (double)ApplicationData.Current.LocalSettings.Values["X"];
    this.Top = (double)ApplicationData.Current.LocalSettings.Values["Y"];
    this.Width = (double)ApplicationData.Current.LocalSettings.Values["Width"];
    this.Height = (double)ApplicationData.Current.LocalSettings.Values["Height"];

    this.MouseMove += MainWindow_MouseMove;

    RadialGradientBrush brush = new RadialGradientBrush();
    brush.GradientStops.Add(new GradientStop(GetRandomColor(), 0.0d));
    brush.GradientStops.Add(new GradientStop(GetRandomColor(), 0.5d));
    brush.GradientStops.Add(new GradientStop(GetRandomColor(), 1.0d));
    root.Background = brush;

    double[] rawPoints = (double[])ApplicationData.Current.LocalSettings.Values["Points"];
    PathGeometry geo = new PathGeometry();
    geo.FillRule = FillRule.Nonzero;
    PathFigure figure = new PathFigure();
    figure.StartPoint = new Point(rawPoints[0], rawPoints[1]);
    PolyLineSegment segment = new PolyLineSegment();
    for (int i = 0; i < rawPoints.Length / 2; i+=2)
        segment.Points.Add(new Point(rawPoints[2 * i], rawPoints[2 * i +1]));
    this.Clip = geo;

    closeButton.SetValue(Canvas.LeftProperty, geo.Bounds.Width / 2 - geo.Bounds.Left - 16);
    closeButton.SetValue(Canvas.TopProperty, geo.Bounds.Height / 2 - geo.Bounds.Top - 16);



If you ever need to add a utility window to your UWP app that is chromeless and/or has an arbitrary shape – or using any of the other rich windowing capabilities that are still missing in UWP, using a desktop extension with a WPF window is a way to accomplish the scenario.

This was a fun sample to put together. I will now continue working on my actual personal app project that triggered the idea for this post. Will share the actual use case in an upcoming post. Follow me on twitter @StefanWickDev to get notfied. Hope you found this information helpful and maybe you can use it in one of your projects as well.



App Elevation Samples – Part 3


If you haven’t read part 1 and part 2 of this series yet, please start there first. I have covered the “hello world” version of a packaged app that requires elevation at launch time and showed how a packaged app can dynamically elevate itself. In this post we’ll get to the fun part: using the ‘allowElevation’ capability from a UWP app to execute code with elevated privileges on Windows 10 desktop with the 1809 update.


I already have the 1809 update and the Windows SDK 17763 (or later) installed. Just show me the code on GitHub …

Sample Code Repo on Github

Step-by-Step Tutorial

1. Create a new Universal Windows App

Make sure you run Windows 10 with the 1809 update and have the Windows SDK 17763 (or later) installed. Now create a new C# Universal Windows application in Visual Studio 2017 (can use any supported programming language as well, e.g. C++, JS, …):


Be sure to set both “Minimum” and “Target” version to 17763 or higher as build number 17763 maps to the 1809 update for Windows 10. The ‘allowElevation’ capability we will be using has been introduced in 1809 and is not available in earlier versions of Windows 10.


Now we need to add a ‘fullTrustProcess’ desktop extension to our UWP that will contain the code we want to run with elevated privileges. For a complete tutorial on UWP desktop extension read up here on all the details. In this post I will quickly move through the steps of setting up the desktop extension for our new UWP app:

2. Add the desktop extension project

For this example we want the desktop extension process to be headless (i.e. a background process without UI). It can have a UI as well if that’s what you need for your scenario. So let’s add a C# desktop console application (of course this could be C++, VB, etc. as well) and call it “Elevated Extension”:

addConsole2We don’t want a console box to pop up for our elevated background process, so we need to configure this project to run headless. For that go into the project settings and change the Output Type from “Console Application” to “Windows Application” (I know, not very intuitive …)


5. Packaging everything together

Next we need to add a “Windows Application Packaging Project” (look for it in the “Windows Universal” category). Name it “Package” and make it the startup project,  so your solution setup looks like in the screenshot below. In order to package both the UWP and the desktop code in one app package, add both as Application references to the Packaging project:


6. Configuring the appx manifest

Now to connect the two projects we need to declare the “fullTrustProcess” desktop extension in the package manifest. For this open the Package.appxmanifest file in the Packaging project (“Package”) in XML editing mode and add the extension within the <Application> node. While we are in this file we are also adding the “appExecutionAlias” extension that we learned about in part 2, as we will need it to launch our extension with elevated privileges. Last but not least, you will also need to add namespace definitions for “uap3” and “desktop” in the root <Package> element per below snippet.

  IgnorableNamespaces="uap3 desktop ...">


    <desktop:Extension Category="windows.fullTrustProcess"
                       Executable="Elevated Extension\Elevated Extension.exe">
        <desktop:ParameterGroup GroupId="User" Parameters="/user" />
        <desktop:ParameterGroup GroupId="Admin" Parameters="/admin" />

    <uap3:Extension Category="windows.appExecutionAlias"
                    Executable="Elevated Extension\Elevated Extension.exe"
        <desktop:ExecutionAlias Alias="ElevatedExtension.exe" />


Note that the the two parameter groups I am defining for the desktop extension are not mandatory. I am doing it here only for this sample to later demonstrate how we can launch the extension with either user privileges or admin privileges.

7. Adding the launcher code

Now that solution and manifest are set up and configured correctly, we are ready to add the code to launch the extension from the UWP – as either elevated or regular process. First lets add some XAML to MainPage.xaml:

<StackPanel HorizontalAlignment="Center" VerticalAlignment="Center">
    <Button Content="Run Backgroundprocess as User"
            FontSize="32" Margin="3"/>
    <Button Content="Run Backgroundprocess as Admin"
            FontSize="32" Margin="3"/>

Before we can add the code-behind for the button click handlers, we need to add a reference to the UWP desktop extension SDK, because that’s where the FullTrustProcessLauncher API is defined. This API, btw, is not new in the 1809 update. It has been around since the Creators Update (SDK build 14393), but it’s recommended you reference the Desktop extension SDK that matches your target version, i.e. 17763 in our case.


Next we add the two button click handlers in MainPage.xaml.cs. The key piece is the FullTrustProcessLauncher API. We are passing in the parametergroup to indicate to the extension whether we need to run it as user or with admin privileges. The processing of this parameter is application logic as we will see in the next step. Wrapping this call into an “IsApiContractPresent” is an important practice to ensure our universal app can run without crashing also on non-desktop devices that don’t support the FullTrustProcessLauncher API:

private async void ButtonUser_Click(object sender, RoutedEventArgs e)
  if (ApiInformation.IsApiContractPresent(
      "Windows.ApplicationModel.FullTrustAppContract", 1, 0))

private async void ButtonAdmin_Click(object sender, RoutedEventArgs e)
  if (ApiInformation.IsApiContractPresent(
      "Windows.ApplicationModel.FullTrustAppContract", 1, 0))

The final piece of code we need to add now goes into Program.cs of the “Elevated Extension” project. This is the code that handles the “/user” vs “/admin” parameter. If the latter has been specified we want to do the same as in part 2, i.e. relaunch the process as admin using the AppExecutionAlias. In case you are wondering why the strings we are handling here are different from the strings being passed to the launch API (“/user vs “User”), take a look at the ParameterGroup entries we added to the manifest. It maps a friendly name (“User”) to what could be in some case a fairly convoluted long string of parameters (“/user” in our case).

static void Main(string[] args)
    if (args.Length > 2)
        if (args[2] == "/admin")
          string aliasPath =
      Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) +

          ProcessStartInfo info = new ProcessStartInfo();
          info.Verb = "runas";
          info.UseShellExecute = true;
          info.FileName = aliasPath ;

    AutoResetEvent areWeDone = new AutoResetEvent(false);
    // do some task, then exit

8. Run and test the solution

Now we are ready to run and test our solution, before hitting F5 make sure the “Package” project is set as startup project and you have added the “allowElevation” capability in its appx manifest:

    <Capability Name="internetClient" />
    <rescap:Capability Name="runFullTrust" />
    <rescap:Capability Name="allowElevation" />

When the UWP is up-and-running use the buttons to launch the extension either as user or as admin. Observe the result in TaskManager, remember that the extension has been coded to exit itself after 10sec in this example:


This concludes my 3-part tutorial about the new ‘allowElevation’ capability. Please leave your feedback and questions as comments and I will do my best to address them in a timely fashion.


Global hotkey registration in UWP


As promised, I am starting now to share a number of concrete scenario samples where UWP apps can light up common desktop features using desktop extensions. In this post my UWP app will register for system-wide hotkeys and handle them – even when the app is suspended.



Just show me the code on github …

Let me run the demo app from the Microsoft Store …



If you have followed my tutorial for desktop extensions you will find this one pretty straight forward, here are the detailed steps to implement this feature from scratch:

1. Project Setup

We are using the same project setup as explained in part 1 of the tutorial, with a UWP project, a C# console project and a Packaging project to tie it all together:


Since we don’t want the console project to actually pop up a console window (or any window for that matter), we need to switch the output type from Console to Windows Application (I know, not very intuitive …):


2. Declaring & Launching the Desktop Extension

Now we can declare the Desktop Extension in the Package.appxmanifest file. Be sure to declare this in the Packaging project, not the UWP project! While we are at it, let’s also declare the AppService. We will need it later to communicate the WM_HOTKEY event back to the UWP process.

 <desktop:Extension Category="windows.fullTrustProcess"
 Executable="HotkeyWindow\HotkeyWindow.exe" />
 <uap:Extension Category="windows.appService">
 <uap:AppService Name="HotkeyConnection" />

Now with this in place, we can launch the Desktop Extension from our UWP app. Before we launch it, we will store our ProcessId in the local settings, so the extension can pick it up and track the lifetime of the UWP. This will help us to clean up and shutdown when the UWP process goes away.

// MainPage.xaml.cs
if (ApiInformation.IsApiContractPresent("Windows.ApplicationModel.FullTrustAppContract", 1, 0))
 Process process = Process.GetCurrentProcess();
 ApplicationData.Current.LocalSettings.Values["processID"] = process.Id;

 await FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();

When the extension launches, it will get to work right away and register the hot keys for our application. Before it can do so though, it needs to create a (headless) window in order to handle the incoming WM_HOTKEY messages, whenever the hot keys get pressed:

// HotkeyWindow.cs
public HotkeyAppContext()
 int processId = (int)ApplicationData.Current.LocalSettings.Values["processId"];
 process = Process.GetProcessById(processId);
 process.EnableRaisingEvents = true;
 process.Exited += HotkeyAppContext_Exited;
 hotkeyWindow = new HotKeyWindow();
 hotkeyWindow.HotkeyPressed += new HotKeyWindow.HotkeyDelegate(hotkeys_HotkeyPressed);
 hotkeyWindow.RegisterCombo(1001, Modifiers.Alt, Keys.S); // Alt-S = stingray
 hotkeyWindow.RegisterCombo(1002, Modifiers.Alt, Keys.O); // Alt-O = octopus


3. Communicating the WM_HOTKEY event

Once we get a HotkeyPressed event (i.e. when we process WM_HOTKEY in our headless window), we create an AppServiceConnection back to the UWP process and send the ID of the hotkey:

// HotkeyWindow.cs
private async void hotkeys_HotkeyPressed(int ID)
 // send the key ID to the UWP
 ValueSet hotkeyPressed = new ValueSet();
 hotkeyPressed.Add("ID", ID);

 AppServiceConnection connection = new AppServiceConnection();
 connection.PackageFamilyName = Package.Current.Id.FamilyName;
 connection.AppServiceName = "HotkeyConnection";
 AppServiceConnectionStatus status = await connection.OpenAsync();
 connection.ServiceClosed += Connection_ServiceClosed;
 AppServiceResponse response = await connection.SendMessageAsync(hotkeyPressed);

Now on the UWP side we handle this request and kick-off off the respective animal animation:

// MainPage.xaml.cs
private async void AppServiceConnection_RequestReceived(
                     AppServiceConnection sender,
                     AppServiceRequestReceivedEventArgs args)
 AppServiceDeferral messageDeferral = args.GetDeferral();
 int id = (int)args.Request.Message["ID"];
  case 1001://stingray
   await this.Dispatcher.RunAsync(CoreDispatcherPriority.Normal, () =>


4. NativeWindow Implementation

The underlying Win32 magic is implemented in the HotkeyWindow class, derived from NativeWindow:

// HotkeyWindow.cs
public class HotKeyWindow : NativeWindow
 private const int WM_HOTKEY = 0x0312;
 private const int WM_DESTROY = 0x0002;

 public static extern bool RegisterHotKey(IntPtr hWnd, int id, int fsModifiers, int vlc);
 public static extern bool UnregisterHotKey(IntPtr hWnd, int id);

 private List<Int32> IDs = new List<int>();
 public delegate void HotkeyDelegate(int ID);
 public event HotkeyDelegate HotkeyPressed;

 // creates a headless Window to register for and handle WM_HOTKEY
 public HotKeyWindow()
  this.CreateHandle(new CreateParams());
  Application.ApplicationExit += new EventHandler(Application_ApplicationExit);

 public void RegisterCombo(Int32 ID, Modifiers fsModifiers, Keys vlc)
  if (RegisterHotKey(this.Handle, ID, (int)fsModifiers, (int)vlc))

 private void Application_ApplicationExit(object sender, EventArgs e)

 protected override void WndProc(ref Message m)
  switch (m.Msg)
   case WM_HOTKEY: //raise the HotkeyPressed event

   case WM_DESTROY: //unregister all hot keys
    foreach (int ID in IDs)
     UnregisterHotKey(this.Handle, ID);
   base.WndProc(ref m);

5. Lifetime Considerations

There are a couple of interesting app lifetime/lifecycle considerations and options in this sample that I want to touch on:

a. Bringing the UWP back to the foreground

When the hotkey is processed in the sample, the UWP is brought to the foreground, so you can enjoy the animation. This is optional and for other scenarios you may chose to leave it in the background. At any rate, we accomplish this by calling AppListEntry.LaunchAsync() on ourselves. This API when called on a running app has the desired effect to bring the app into the foreground, even when the UWP process was suspended.

b. Lifecycle of the Desktop Extension

In this sample the extension’s lifecycle is coupled with the UWP app’s lifecycle. This makes sense here since we want the hotkeys to only be registered while the UWP is running (or suspended), not beyond that. That’s why we are tracking the UWP process and will unregister the hotkeys and shutdown the extension when the UWP goes away.

However, the extension lifetime is in your control and for a different scenario you may choose to keep the extension process alive even after the UWP process goes away.

c. Lifetime of the AppServiceConnection

On every WM_HOTKEY message we open an AppServiceConnection to the UWP, which we will then close once it has been processed. We could also choose to keep the connection around for the lifetime of the process, but this would have the unwanted effect that the UWP would never suspend when minimized and therefore use more system resources than it should.



C# Code for the headless window to handle WM_HOTKEY inspired my this Stackoverflow answer:

Tile icon for the Store sample provided by