Desktop Code Windows Xamarin

WPF Activity in Xamarin Forms

I’ve recently been working on extending an existing product written in Xamarin Forms to Windows desktop and this has meant learning a lot more about the WPF implementation. Originally Xamarin Forms was created for mobile platforms such as Android and iOS (and Windows Phone – more on that later) but has since expanded to desktop platforms such as macOS, GTK and WPF on Windows (UWP originally straddled mobile and desktop). WPF is a more recent addition to Xamarin Forms and so understandably the implementation is less mature. It does follow the native look and feel closely but I soon found quite a jarring omission.

Our app uses the ActivityIndicator to represent indeterminate activity. On Android et al. this displays a rotating circular spinner but on WPF it was using an indeterminate progress bar squashed into a rectangular space which looked odd. This is understandable as there is no native control in WPF. I then had a flash of deja vu when thinking about something I wrote some time ago for Windows Phone!

Windows Phone 8.1 introduced the WinRT application model (from Windows 8) alongside the existing Silverlight approach but there were some complications and some types of apps could only be written in Silverlight. I created a library called Charming which added some of the Windows 8 style APIs to the Silverlight app model. This was later expanded and became Pontoon. One of the APIs was a Silverlight ProgressRing control which looked just like the Windows 8 equivalent. The progress ring still regularly appears in the Windows shell and is implemented in UWP. Since Silverlight is a subset of WPF it was straightforward to port it into the Xamarin Forms WPF platform library and modify the renderer for ActivityIndicator. Voila! A nice native looking ActivityIndicator for Windows desktop apps. This has now been merged into the Xamarin Forms code and should appear in a preview release soon alongside the MediaElement that also got merged recently. Until it hits a stable release you can add it via InTheHand.Forms too.

Desktop Code Windows 10

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 AssembliesMicrosoftFramework.NETCorev4.5System.Runtime.WindowsRuntime.dll

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

C:Program Files (x86)Windows Kits10UnionMetadataWindows.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.

Desktop Code Windows Windows Mobile Xamarin

Introducing Pontoon – A flexible bridge to the Universal Windows Platform

I first created the “Charming” libraries for Windows Phone in order to add some APIs which were added to Windows 8 but not available on phone. Many of the early ones replicated the “Charms” related functionality (Sharing/Search/Settings) hence the silly name.

When I created version 9 about a year ago I consolidated lots of separate libraries into just two – InTheHand and InTheHand.UI. The latter contained UI specific functionality such as MessageDialog, ToastNotification and ApplicationSettings. Following this I extended the library with support for iOS and Android using Xamarin and exposing the same UWP style API.

As I’ve been doing Xamarin development recently I’m constantly having to look for or write wrappers for native APIs to use across platforms. You sometimes find libraries which claim to provide a cross-platform API but actually only support iOS and Android. I looked at the large codebase I already had and thought about other areas which could be implemented across all the Windows and Xamarin platforms. Among the Windows platforms I added Win32 support so you can use these same APIs from Console, WinForms or WPF applications on versions prior to Windows 10. Since a lot of desktop apps still support Windows Vista and 7 this was very important to provide future code compatibility with Windows 10.

I’d toyed with changing the name before because it’s now irrelevant in an OS which no longer has the concept of Charms. I thought about the Windows 10 “bridges” – to take Desktop Apps, iOS and Silverlight to UWP and thought what I have here is effectively another bridge. It’s a flexible one though and it also works in both directions. You can code C# on numerous platforms and that code will be instantly portable to UWP. You can also use your UWP knowledge to easily target some of the more fiddly aspects of Xamarin platforms consistently. If you consider a Xamarin Forms application which might target iOS, Android and Windows once you step beyond laying out forms with the built in controls and basic page navigation there is no common API to work with Settings, Files, Geolocation, Network connectivity and more. If you are able to find a NuGet library which supports all the platforms you need you’ll have to learn a whole new API too. One word which kept springing to mind with the concept of a flexible bridge is Pontoon and so this is what I chose. Wikipedia says “A pontoon bridge, also known as a floating bridge, uses floats or shallow-draft boats to support a continuous deck for pedestrian and vehicle travel”. Although I renamed the GitHub repository this is a direct continuation of the Charming codebase but there will be a few breaking changes hence the new NuGet package and major version change.

If you are interesting in contributing to the library please do get in touch. There are a number of open issues which are still to be addressed and many more API areas which would make sense to implement in this way. I’ve consciously avoided most UI areas because this is something you’ll need to approach differently for each platform (unless you use Xamarin Forms) and I didn’t want introduce any additional dependencies. There are some UI elements such as StatusBar, MessageDialog, Toast/Badge notifications, CameraCaptureUI etc. I consider these to be part of the “Chrome” rather than your app UI – they will all have a very different look and feel depending on the platform but perform the same functions.

I’m still working on a sample application. I’ll probably use Xamarin Forms in order to create a simple UI to surface as much of this functionality as possible.

As always I welcome all constructive feedback – please use GitHub to raise any issues.





Desktop Code Windows Mobile

Desktop ActiveSync Registry Settings

In March I showed how to get the version of a connected device from the desktop. This post documents the rest of the registry settings used to store device information. There are two registry locations, the first at HKEY_CURRENT_USERSoftwareMicrosoftWindows CE Services contains information about the currently connected device. The second, HKEY_CURRENT_USERSoftwareMicrosoftWindows CE ServicesPartners contains information for each of the partnerships established on the desktop PC.

When the device is docked, regardless of whether a partnership is established, the following keys are populated in HKEY_CURRENT_USERSoftwareMicrosoftWindows CE Services:-

  • DeviceHardwareId -String containing a unique Guid for the device

  • DeviceOemInfo – OEM specific string (as returned by SystemParametersInfo using SPI_GETOEMINFO) e.g. WIZA200 (HTC Wizard)

  • DeviceProcessorType – DWORD value – 2577 (ARM) for all Windows Mobile devices

  • DeviceType – string containing platform type (as returned by SystemParamtersInfo using SPI_GETPLATFORMTYPE) e.g. PocketPC or SmartPhone

  • DeviceVersion – DWORD value – see my previous post.

The partnerships are stored with a unique DWORD partnership id e.g.

HKEY_CURRENT_USERSoftwareMicrosoftWindows CE ServicesPartners12345678

There are additional values to describe sync behaviour and some Windows Mobile Device Center specific values e.g. to specify the display icon for a device. Otherwise all of the above values are duplicated here for the partner device, except with some naming differences:-

  • DeviceHardwareId

  • OemInfo

  • ProcessorType

  • DeviceType

  • Version

Each partnership has a directory containing any resources used, this includes the icon etc. The path is retrieved from the DataFolder value. This is a path beneath the users roaming application data folder which you would get using System.Environment.GetFolder(System.Environment.SpecialFolder.ApplicationData)

The icon is specified in DeviceIconFile and if you append this to the path you’ll have the full filename of the icon.

Desktop Code

.NET Framework 3.0 Released

I’m still not a huge fan of the naming system used – v3.0 is the v2.0 framework with what was previously known as WinFX added – Windows Communication Foundation, Windows Presentation Foundation and Windows Workflow. You can download the redistributable here:-

Desktop Code

Indigo Reaches Beta 2 And Gets Go-Live License

Indigo (Yeah I know I’m supposed to call it Windows Communication Foundation), has reached the Beta 2 milestone. With this release you can apply for a Go-Live license to deploy the technology in live environments*


Read all about it here:-


*Terms and conditions apply. Your small print may go down as well as up.

Bluetooth Desktop Code NETCF

Bluetooth Remote Control

Mike Hall posted a link on his blog to a channel9 interview with Anil Dhawan from the Windows Mobile team discussing Bluetooth programming, which I recommend you check out. Anil gave a demo of a native code application to remote control PowerPoint on a desktop PC. This inspired me to put some finishing touches to a test application I built for the Bluetooth .NETCF library – It is by no means finished but it works (with the wind blowing in the right direction!).

There are two components, on the Smartphone an application which you first select Search from the menu and it will do a lookup of local discoverable devices, then select one and select the Connect menu option. Once connected any d-pad or number keys are captured and sent over bluetooth. As I said it was an unfinished project, key items missing are:-

  • Store desktop address in the registry so we only have to search once

  • More intuitive interface 🙂

  • Support for key mapping – map the device keys to application specific commands e.g. for media player etc

On the desktop a simple listener which listens on a custom service, incoming data is received as keycodes which are broadcast on the system using the SendKeys.Send method.

On an unrelated note, thanks to Sergey Bogdanov who has contributed an implementation of the SendKeys class to be included in the upcoming SDF v1.3 release.

With the listener application running and the Smartphone client connected you can automate (within reason) whatever app has the focus. It works great for Powerpoint browsing between slides using the d-pad on the phone. The usual disclaimer applies – this works only with the Microsoft Bluetooth stack on both device and desktop, I tested with an Orange SPV C500.

The two projects are available to download here.

Desktop Code

System.Net.IrDA for the desktop (Part 2)

Following my previous post, I did some further development to the code to make it fully match the .NETCF assembly (yes, in my haste I’d missed a few properties and cut a couple of corners). So now I have compiled a System.Net.IrDA.dll assembly which has exactly the same classes and methods as is available in device projects. So you can easily move device code over to Tablet and laptop PCs.

Download the DLL here (zip 7kb)

The package includes just the dll and xml documentation. The next task for the project is to build an installer for both the source and binaries…

This was a useful learning experience since I’ve based the Bluetooth code on the existing model of the IrDA library, so it was useful to spend some time studying this particular library and the classes it contains.

The functionality is now part of 32feet.NET a library for personal area networking for .NET. The downloads are here:-

Desktop Code

System.Net.IrDA for the desktop

Following on from a question which cropped up on today’s MVP chat. I did some investigation into IrDA support on the desktop framework. Turns out you can’t use System.Net.IrDA.dll from .NETCF on the desktop as I had read on some blog, but since the basic Socket class supports the IrDA address family, it is necessary to build a couple of helper classes for the IrDAEndPoint and IrDAClient and IrDAListener to match the .NETCF implementation. I built these rather hastily and therefore have omitted a few overrides and non critical items. I intend to flesh this out later to fully match the .NETCF class. However the code zipped up below will give you the classes necessary to migrate your .NETCF IrDA code to the desktop. It was tested using the sample code in the .NETCF Quickstart on the subject to Discover my Pocket PC and send it a file. When I get the chance I’ll compile it into a System.Net.IrDA.dll, for now you’ll have to make do with C# source, and I didn’t really stop to write comments this evening – sorry 🙂

Download Source

Desktop Code NETCF

Hosting a Native Windows Control – The desktop approach

Following Neil’s recent post on my control hosting article, I realised that the article had not gone into detail on the differences between the Control class in the full framework and Compact Framework. The Control class in the full .NET framework is incredibly powerful, and when I built the ControlEx class to enable hosting I tried to work to the same model where possible. Generally the Compact Framework follows the design of it’s larger cousin and therefore if the functionality of the Control class is enhanced in future revisions of the Compact Framework it will likely follow a subset of the desktop functionality.

There is a key difference with the Control class on the desktop, than any custom Control derived class on the Compact Framework. On the desktop you can override the protected CreateParams property to force the control to create any window class (remember that in Win32 terms any control is considered a window with it’s own unique handle and based on a specific window class). It’s possible to create an intrinsic windows control like the SysAnimate32 with almost no need to resort to Platform Invoke. If you view the running program with a tool like Spy++ you’ll see the SysAnimate32 window is a direct child of the form it sits on. We can pass it messages entirely in managed code by simply calling it’s WndProc method. The Handle property for the control is the handle for the SysAnimate itself.

On the Compact Framework this behaviour is only true for the standard set of Controls in System.Windows.Forms. For all other controls a standard window class is created (and this we have no control over), any native window class we wish to use must be added as a child to this window. However the next main hurdle with the .NETCF Control class is that there is no WndProc method we can override, so if we create a window as a child of this control, we have no way of capturing it’s window messages (Unless we capture them in the application message loop itself using ApplicationEx). Therefore to implement a WndProc for the control we use an additional layer.

The MessageWindow class is specific to the Compact Framework and serves only one purpose, it allows us to receive messages within managed code. By default the MessageWindow is a hidden 0x0 pixel window. With some P/Invoke magic it is possible to alter the size and position of the MessageWindow to make it a visible control – this is our empty canvas. We now create the native window as a child of this window and we have a native control, housed within a managed control with the ability to both send messages to the control and, most importantly, receive notification messages and process them.

There are a few house-keeping chores required to keep this three-layer solution working. Whenever the control is resized we must resize both the child (MessageWindow) and grandchild (native control) to fit. In order to hide as much of this plumbing as possible, and to avoid re-inventing the wheel, the ControlEx class was built to do all this work for you. Like the Control class on the desktop it exposes a CreateParams property which you can override with your class type. Notification messages received from the native control by the MessageWindow are passed to the OnNotifyMessage method of the ControlEx. It’s not quite as powerful as the full WndProc of the desktop but it allows us to receive events such as item selections within the native control. The WebBrowser sample within the article download uses these to expose events when the user taps a link.

The HtmlViewer, MonthCalendar and InkX controls within SDF v1.2 are all built using this technique, however they use a less transparent approach to the new ControlEx class. I’ll be upgrading these to use the ControlEx class, and of course you can use the class yourself to wrap other native windows controls of your choice.

You can download a sample “Trash It!” project here which is a desktop .NET project which wraps the SysAnimate32 control to display a delete animation. The only P/Invoke required is LoadLibrary / FreeLibrary to load the dll containing the AVI animation resource. This should provide some contrast with the WebBrowser class in the article.