Calendar Import is Back

I was almost at the point of retiring the app since Mail & Calendar has supported iCalendar (.ics) files for a while now. Then I came across a scenario where the app is still required. vCalendar files (.vcs) are very similar but use version 1.0 of the vCalendar spec whereas iCalendar is version 2.0. Mail & Calendar still can’t open this format at the time of writing.

I’ve updated the UWP app for Creators Update and later and it now just registers for .vcs files (all .ics files will be handled by the Calendar app and this avoid the OS popping up a choose app dialog unnecessarily). Doing the update also made me check that it could work on Surface Hub and HoloLens (although it just uses the standard 2D Calendar UI). If you get .vcs files via email attachments or online this is a really simple (and free) app to import them into the Windows Calendar.

Download from the store for all Windows 10 devices:-


Using specific versions of UWP from Win32

From a Win32 .NET library (One that targets desktop apps whether Console, WinForms or WPF) you can add two references and take advantage of (most) UWP APIs.

The first is a .NET library which handles interop with the UWP / WinRT APIs:-

C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETCore\v4.5\System.Runtime.WindowsRuntime.dll

The second is the metadata for the UWP APIs themselves:-

C:\Program Files (x86)\Windows Kits\10\UnionMetadata\Windows.winmd

This describes the v1.0 versions of the API Contracts. These are expanded with each Windows 10 version and so you may find you want to target newer APIs and they are not available here. In a UWP project you can easily toggle the minimum target version of Windows 10 and this defines the API surface available to you. No such option exists for this kind of interop so instead you can switch the Windows.winmd reference for an alternative version. These are installed into subfolders of the above folder with the build number of each installed SDK. The latest released version for the April 2018 update is in 10.0.17134.0. As with UWP development you need to choose your API level carefully as it will affect which machines you can deploy to. For a library developer you need to ensure you document the minimum version you support to avoid any surprises.

Adventures in Desktop App Conversion

The Desktop App Converter (or Project Centennial) is a way of packaging up traditional desktop applications in appx format for the Windows 10 store. You would commonly use it for modernising an existing app. This allows you to take advantage of store distribution and incrementally add modern functionality to it.

My requirement was a little different. I needed a way of adding functionality to a UWP app which is not currently possible via UWP. The functionality in question was the ability to show a progress bar on the desktop taskbar entry. If you don’t know what I mean by this it is what you get with many desktop installers or other apps which make large downloads to keep you informed of progress while you do something else. There are two ways of approaching this – you can include a desktop “full-trust” component inside the same app package as a UWP app allowing you to mix and match and submit to the store as a single entity but this requires the developer to get full trust certification each time you repeat the process. The other approach is to build a standalone desktop bridge app to call the Win32 APIs necessary to control the taskbar and have other UWP apps call into this via an API. This way once the enabling app has gone through certification subsequent UWP apps can make use of it without any special permissions. Underneath there is a simple Uri scheme to request taskbar changes and so the caller won’t throw an error if the “Taskbar Progress” app isn’t installed.


taskbar test (2)
Taskbar Progress in a UWP app


The API to call this is already part of Pontoon as theĀ InTheHand.UI.ViewManagement. StatusBarProgressIndicator. This mirrors the API in UWP which is only available on phone devices. We wrap the functionality for you so there is a common API across mobile and desktop flavours of Windows as well as Android and iOS (although iOS is limited to a indeterminate spinner).

I have a very basic sample app which I’m just waiting to convert from private to public in the store and will update this post with a link when published.

Get Taskbar Progress from the Windows Store

Pontoon on GitHub

GitHub Latest

While I prepare to refresh my main machine with Windows 10 Creator’s Update and the latest Visual Studio and Xamarin updates I thought I’d throw together a summary of open-source progress since I last blogged:-

Since the announcement of CodePlex’s upcoming retirement I’ve been moving projects across to GitHub. 32feet and my Compact Framework archive are now moved, there is just some tweaking to be done on the Wiki content for the former. I’m planning a blog post on the process I’ve used.

I’ve reworked the existing documentation site which was hosting the Pontoon documentation and it now also contains InTheHand.Forms and 32feet documentation. The Compact Framework stuff may follow but it depends on getting the dependencies setup just right for the help file builder.

Pontoon has had a number of enhancements. I’ve been refactoring the code to better handle the number of different platforms which are supported. This has also allowed me to identify gaps and fill some of them. Android now has InTheHand.Devices.Radios support for Bluetooth and the ability to launch any StorageFile with Launcher.LaunchFileAsync. macOS now has full support for local and roaming settings as-per iOS.

Talking to Printers

Recently I’ve been working with a selection of Bluetooth printers. During this work I’ve noticed an odd thing about the UWP Bluetooth APIs. It’s all about the Class of Device. These are a set of defined device types and are categorised into major and minor classes. For example a Printer has a Major class of Imaging and a Minor class of Printer. In the raw form the class of device is a bitmask and the bits reserved for the major class define the behaviour of the rest of the bits. The UWP API exposes a BluetoothClassOfDevice class and this has two properties – MajorClass and MinorClass and each uses an Enumeration. The interesting thing with this approach is that the MinorClass values overlap but have different meanings depending on the major class. There are already multiple fields with the same value – ComputerDesktop, PhoneCellular and PeripheralJoystick for example. For whatever reason all of the Imaging minor classes are missing – they all pre-date the original WinRT codebase so really should have been included.

I created a gist to pull together my helper method and enum to make identifying printers a little easier. I created an extension method to return the correct minor class when you identify a device with a major class of imaging:-

All New Clipboarder

My free Clipboarder app for Windows Phone has now (finally) been re-written as a universal Windows 10 app. It’s currently available across all Windows 10 platforms (except Xbox but that seems fairly logical!). The app provides a share target allowing you to share data from modern apps to the clipboard to be pasted into any app (old or new, doesn’t matter as long as it has text input). A new feature made possible by using UWP is roaming content across devices. You can share something to your clipboard on your phone and then use it from the Clipboarder app on your desktop PC. The app still supports the clipboard Uri scheme in case you’ve been using it for clipboard access in Windows Phone 8.1 (appx) apps.

Download from the store (Free):-