Xamarin Forms Windows Colours

When you work with custom renderers on Xamarin Forms (and it’s very difficult not to!) you often have to convert from Xamarin Forms types to their native platform equivalent. In the iOS and Android implementations Xamarin include some extension methods to easily convert Color to the native equivalent. Being the Cinderella of the Xamarin Forms platforms Windows platforms have missed out on this so I’ve filled the gap with this handy extension method:-


This works for Windows Phone 8.1, Windows Store and UWP targets (sorry I haven’t created the Silverlight equivalent)

Ordering the Surface Pro 4 Docking Station Adapter

If you have a Surface Pro 3 Docking Station and want to use it with Surface Pro 4 you’ll probably have heard that you need an adaptor – a thin sheet of plastic which it seems is as elusive as hens teeth. You’ve possibly read the instructions here http://winsupersite.com/hardware/microsoft-finally-works-out-its-surface-pro-4-surface-pro-3-docking-station-spacer and here is the rest of the process:-

Once you’ve selected “Replace an accessory” you’ll need to pick your device. Assuming you’ve already registered you just have to click on your Surface Pro 4 here. Then you’ll see choices for categories “Pens and Loops”, “Docking Station”, “Other”. You’ll need to select Docking Station and you may get a popup asking you to enter a product number. Of course you don’t have a product number for a product you don’t have so don’t panic. When you select that you don’t have a product number ignore the warnings that your product will be considered out of warranty. What should happen on the next screen is that only one product is available which is the adapter at an extravagant £0.00. You’ll also have to pay postage – for the UK this is £4 (+VAT). There is a drop down box for shipping type but this has only a single choice “No Action Required”, enter your shipping details and proceed to pay.

I guess £4 is the “price of inaction” 🙂

Windows Embedded Compact 2013 & Visual Studio 2013

The latest update to Windows Embedded Compact 2013 was a bit of a surprise as besides the usual cumulative bug fixes and tweaks it adds development support with Visual Studio 2015. Since the days of Windows Mobile 6 and even CE 7 it has been common to use an old version of Visual Studio to get things done but here the tools have jumped to the latest Visual Studio version.

Besides the usual Console and Windows Forms project types we’ve tested XAML In The Hand too and you can build managed code XAML based applications. You can debug over Ethernet, edit your XAML with intellisense, use NuGet packages etc all as you would with “big” Windows development.


One of the new features added in Compact 2013 was Behaviors and while you can use them already in XAML In The Hand projects from your XAML we’re investigating whether it might be useful to add code support for these too depending on demand.

The Compact 2013 installation is in two parts – Application Builder is the plugin for Visual Studio:-


The latest Compact 2013 Platform update is here:-


More details on XAML In The Hand can be found here:-

XAML In The Hand


Xamarin Forms Password Entry on Windows Runtime

Xamarin Forms doesn’t have a specific PasswordBox control – instead you use the Entry (Think TextBox) and set IsPassword to true. Normally this works as expected and provides a masked entry box. However there is a known issue on Windows Runtime (Phone and Desktop) where AutoSuggest and Auto Capitalisation are not disabled for a Password field. Luckily there is a workaround which is to set the input keyboard to Email. The small side effect is the addition of a “.com” button to the keyboard but it will stop the control capitalising the first letter or showing suggestions based on what you are typing. I added the following code behind:-

if(Device.OS == TargetPlatform.Windows)
   txtPassword.Keyboard = Keyboard.Email;

This issue doesn’t affect Silverlight apps (TargetPlatform.WinPhone) and I decided not to set the keyboard on other platforms as they work correctly with the default keyboard.

Add Sharing to your UWP App

With Windows 10 the original Charms introduced with Windows 8 have gone. Old Windows 8.x apps will display a window menu with those commands if supported in the app e.g.

Window menu on Windows 8.1 Apps
Window menu on Windows 8.1 Apps

You’ll also notice the icon has changed in Windows 10 to a kind of “three person group hug from above” image whereas they had a kind of clockwise movement to them in Windows 8.1. When you take a look around the first-party apps in Windows 10 many make use of the same Share functionality but it is implemented within the app UI, either in an AppBar or somewhere relevant within the body of the app. For example Edge displays the Share button prominently at the top right of the window. The Store app displays a Share link inside the details for a specific app. Once you tap this the share experience is very similar to Windows 8.x.

Windows Phone never supported charms but did provide the same sharing API from 8.1.  My Charming project originally started out by providing these for WP8.0 apps. Apps would have to add a Share button to the AppBar or menu and trigger the full-screen sharing experience. Moving your app to Windows 10 you will want to make use of sharing wherever it is relevant to your app. Taking an approach like Edge would mean adding a TopAppBar. You might use something like the following XAML:-

      <AppBarButton Label="Share" Icon="Share" Click="AppBarButton_Click"/>

Until you realise that there isn’t an Icon called Share. It’s not a member of the Symbol enumeration which defines common symbols taken from the Segoe MDL2 Assets font. Luckily the actual glyph is available and we just need to use slightly longer syntax to specify it using a FontIcon:-

      <AppBarButton Label="Share" Click="AppBarButton_Click">
          <FontIcon FontFamily="Segoe MDL2 Assets" Glyph="& #xE72D;"/>

That defines a visual element to start sharing, there are two tasks to be completed to allow successful sharing:-

The handler for that button click must call the API which displays the Sharing prompt on screen. On Windows PCs this pops out from the right-hand side and on phones it is a full page view. The code can be as simple as this:-

private void AppBarButton_Click(object sender, RoutedEventArgs e)

The other vital part of the process is to setup an event handler for the DataTransferManager which is called when the Share screen appears and asks your app for available data:-

Windows.ApplicationModel.DataTransfer.DataTransferManager.GetForCurrentView().DataRequested += MainPage_DataRequested;

The handler for this merely checks the presence of some text and if available shares it:-

void MainPage_DataRequested(Windows.ApplicationModel.DataTransfer.DataTransferManager sender, Windows.ApplicationModel.DataTransfer.DataRequestedEventArgs args)
      args.Request.Data.Properties.Title = Windows.ApplicationModel.Package.Current.DisplayName;
      args.Request.FailWithDisplayText("Nothing to share");

This is only a very basic example. The package title is merely the app name. Imagine you have a news app – you may want to share the article title and a Url to the article on the web. You will probably want to control the availability of the Share button. For example in Edge the button is disabled while a page is loading and enabled once your sat on a finished page.

By adding a Share button to your app you open it up to a variety of targets with very little investment – suddenly you have a mechanism to share your app content across social networks, email and productivity software like OneNote. Unlike Windows 8 you have the power to control the visibility and location of the share command so it fits best with how your app works – but it makes sense to use the same icon as your users will be familiar with this from elsewhere in the system.

ShowEditNewAppointmentAsync Weirdness

The Windows.ApplicationModel.Appointments namespace in Windows 8.1 (and Windows Phone 8.1) provides access to the user’s calendar. Prior to Windows 10 there were big differences in the APIs as Phone had the existing capability to extend the calendar with app-specific calendars. Now the API is unified across Windows devices but there are some changes to be aware of which will affect existing apps as well as new ones built for Windows 10.

On Windows Phone 8.1 there were two APIs for displaying a new appointment – ShowEditNewAppointmentAsync shows the edit view with the fields pre-populated with the Appointment object you supply. The second API is ShowAddAppointmentAsync which is shared with Windows 8.1. On Phone however it would display the same edit view as ShowEditNewAppointmentAsync. The screen co-ordinates you pass are ignored as the dialog is fullscreen.

On Windows 8.1 only ShowAddAppointmentAsync existed and this displayed a read-only popup view of the passed in Appointment. With just the option to save or discard the appointment (and ability to select which calendar to save in if you have multiple accounts).

If you call either of those two APIs for Windows Phone on a Windows 10 Mobile device you’ll get a different experience. Now you see a read-only fullscreen dialog showing the details of the appointment but you can tap an edit button in the appbar to fully edit the item. You’ve not lost any functionality as such but it is an extra step to get to an edit screen which is especially annoying if that is what you specifically requested.

Calendar Display > Calendar Edit

If you call either of those APIs on a Windows 10 PC you’ll get the Calendar app which will show a read-only view of the appointment with the ability to save or discard. There is no edit functionality available at all. If you’re running in Tablet mode Calendar will launch fullscreen, otherwise it just pops up a window over your app. It will be much bigger than the popup used in 8.1.

What’s wrong with this? Given the Calendar application is shared across both device types I’d expect the full version to support editing like the mobile one does. If you click “New Event” in the Calendar app you get an edit screen – this is what I’d expect from ShowEditNewAppointmentAsync. I’d also expect the same edit button on the read-only view.  I’d expect ShowEditNewAppointment to open the edit view by default – otherwise there isn’t any point in having two different APIs which do the same thing. I’m hoping that with Mobile still not finished there is time to fix that, or maybe it just needs a tweak to the Calendar app.