WinRT gotcha – “one shot” Timer BackgroundTask does not unregister after the “one shot”

First up – sorry Jack Reacher fans, this post is not about the novel¬†ūüôā .

In my¬†latest Windows¬†10¬†app Event Countdowns¬†I made¬†a¬†very¬†unlucky¬†mistake. When registering¬†its Background Task that should¬†update the¬†app’s tiles¬†every 30 minutes, I used the following code:

At first glance, nothing out of the ordinary. Or so I thought. One day after the app was released, I checked my pinned tile counting down to the premiere of Captain America: Civil War to find out with my immense surprise, that the time left on the tile was off by a day! I immediately checked the code and after a few minutes of intense debugging frenzy found the hidden evil – the second parameter of the TimeTrigger class’ constructor.

The second parameter, oneShot, specifies, whether the task will be triggered only once (value true) or periodically (value false).

My course of action was to just change true to false and because the app worked well when tested on my PC, I published the updated version to Store.

When the update arrived on my phone, I happily installed it, launched it and waited for the tiles to become “live” again. So I waited. And I waited. And I waited. And… nothing.

I was lost. The app worked perfectly on my PC and¬†but tiles just didn’t¬†update on my phone. So I went back to the drawing (Visual) board (Studio) and thought it all through again.

And then I saw it.

I naturally presumed, that once the oneShot Background Task is triggered, it is automatically unregistered by the system. In fact, that is not the case.

Once a oneShot trigger runs the Background Task, the task still stays registered!

This means that when I installed the updated app on my phone and run it, the if check for task != null  evaluated to true, because the task was still registered, although it has already fired once!

The final solution was then to force unregister the existing task to make sure the task is registered again with oneShot set to false.

The bug is finally captured and tiles live on!

 

How to fix Visual Studio shortcuts when ReSharper doesn’t play well

Let me say this РReSharper is a wonderful and almost indespesable tool for C# development. The improved IntelliSense features and automatic using statements are themselves worth having it installed. But sometimes it stops playing well with Visual Studio keyboard shortcuts. Quite often shortcuts like Ctrl + F (Quick Find) shortcut stop working when Resharper is first installed on a PC with non-US default keyboard.

Some keyboards require different ways to write things like braces and similar. For example on the default Czech keyboard, you have to press Alt Gr¬†+ F to write the left square bracket ( ‘[‘ ). Somehow, Resharper for some accidental reason assigns the command it uses for containing declaration¬†(which is normally written as Ctrl + [) to Ctrl + F leaving out the Alt Gr modifier. This way the shortcuts using these unusual characters get broken.

When you find yourself in such a situation, you can luckily fix it quite easily! First change your Windows keyboard layout to US. Then open Visual Studio and opent the Options dialog via the Tools menu. From the left hand pane select Keyboard. Here select the keyboard mapping scheme you prefer (usually ‘(Default)’) and click the¬†Reset button, confirm with Yes and close¬†the options dialog by clicking OK.

KeyboardLayout

Now you probably want to also recover some of the useful ReSharper keyboard shortcuts (no one with ReSharper installed could just live without the all-mighty Alt + Enter shortcut!). You can do just that by going to the ReSharper menu, choosing Options, navigating to Keyboard & Menus and then simply select your preferred shortcut override, click Apply Scheme and Save changes. Now you can try out the command which was broken before and confirm it works well.

Resharper

Now you can safely go back to the keyboard layout of your choice and the commands will be at your service.

WinRT KeyDown fired twice when Enter is pressed

I have noticed a very unusual oddity which occurs when handling the KeyDown event. When the user hits the ‘Enter’ key, the event is actually fired twice (at least this is the case for TextBox¬† and PasswordBox¬† controls on which I have noticed this behavior).

Consider the following code snippet:

What will actually happen when the user actually presses the ‘Enter’ key in the TextBox¬†?

As you would expect, the event is fired first time and frame navigates to SomeOtherPage . But right after the execution of the handler finishes, it is called once again with the exact same arguments! The code will get executed again and the frame will once again navigate Рwhich is (probably) not what you actually needed!

This behavior is really connected only with the ‘Enter’ key and it does not seem to be present for other keyboard keys. Luckily the workaround is simple:

By setting KeyRoutedEventArgs¬†‘ Handled Property to true we are essentially stopping subsequent bubbling of the event higher up the tree, but this also prevents the event to fire again on the same control.

I have reported this issue in the Windows Feedback app for Developer Platform. If you want to support its resolution in future versions of UWP, vote for it by clicking here.

How to show touch keyboard on touch interaction with WPF TextBoxes

Updated November 2016 – .NET Framework 4.6.2

Windows Presentation Foundation (WPF) apps have a bit harder life in the touch-enabled world. In WinRT apps, the touch keyboard shows up automatically when a text field gets focus so that the user can type without the need of a classic keyboard (no¬†interrupting of her touch workflow). For classic desktop apps the situation differs – TextBoxes don’t cause the touch keyboard to appear and the user has to¬†open it¬†manually. That is obviously very cumbersome.

TouchKeyboard
Hey! How can I get you to my WPF app?

There are two different workarounds for this problem.

The hack-y way

The first solution is quite a bit of hacking. This requires us to turn off the inking support for our WPF app and actually force the system to behave the right way. You will need some¬†COM import and call¬†native Windows API. This process is extremely well described here on Brian Lagunas’ blog and I encourage you to try it out. If it works for you, great!

The disadvantage of this solution, that I discovered, is that it¬†interferes with touch “panning” of ListBox controls. Any try to do touch panning only fires ItemClick events on the hovered items and the user needs to scroll using the small scroll bar and that is more than inconvenient.

The simple, but more manual way

To overcome the issues that come after disabling inking support in your WPF app, we can go with a simpler but less automatic solution. We will extend the TextBox control and change its behavior when it gets touch focus.

So how does this work?

When the TextBox receives focus after the user enters it with touch, the GotTouchCapture event is called. In this event we can manually start up the process of touch keyboard. The touch keyboard is just a classic desktop application that lives¬†on the path¬†“C:\Program Files\Common Files\Microsoft Shared\Ink\TabTip.exe”.

This solution is very simple and doesn’t require any “hacking” per-se. The only disadvantage is that you as the developer have to ensure, that you use this modified version of TextBox control every time you need to get the right touch-based behavior.

Killing the process

A logical extension to this is to kill the touch keyboard process when it is no longer needed Рthe input loses focus. The Process.Start( string ) method returns an instance of Process class which provides a Kill() method that will terminate the process when called.

First we need to store the process instance in a private field of the TextBox:

Now we wire up the LostFocus event:

 

Update РWindows 10 way

In Windows 10, this becomes much less of a problem thanks to the new Tablet mode and settings.

Tablet mode

tablet-modeThe newest version of Windows brings a new mode called Tablet mode, which can be turned on via the Action center or in Settings app, and which¬†is optimized for touch first usage. While some see the way¬†it works as a downgrade opposed to Windows 8.1, it presents much more inuitive¬†integration of both¬†new Windows Store apps and¬†classic desktop applications. Each app defaults to full-screen while preserving the multitasking option of two apps side-by-side. Another¬†nice consequence of turning the Tablet mode on is that the touch keyboard is automatically triggered every time any text field gets focus, no matter the type of application. This undoes the need to launch the touch keyboard manually and lets the operating system take the wheel and ensure everything is handled corretly. The only disadvantage as opposed to the modern applications is the fact, that keyboard doesn’t shift nor resize the app window and overlays it (even in case it is pinned to the bottom of the screen). This means, that some content may become invisible (for example tooltips or context menus).

Outside of Tablet mode

But what about the case when you, for some reason don’t want the Tablet mode on but still want to enjoy the automatic handling of text input by the operating system? A inconspicuous setting can make just this happen!

Open the Settings app, go to Devices category and select Typing¬†– here scroll down and you will see a setting that is by default turned off (for some reason, I can’t really understand why) – to show the touch keyboard in case of input while no keyboard is attached. This is the perfect solution for most cases and makes using all apps with touch a very pleasant and consistent experience.

touch

Updated – .NET Framework 4.6.2

In August 2016 Microsoft announced a new update of .NET Framework 4.6.2. In addition to a very useful addition of Per-Monitor DPI for WPF, this update also addressed the problem with touch keyboard.

WPF apps targeting the new version of the framework support automatic invocation and dismissal of the touch keyboard, matching the behavior of UWP apps on Windows 10. That means you don’t have to make any additional¬†changes to your new apps to support the touch keyboard.

softkeyboard

Conditionally copying native libraries to output

With platform dependent native libraries like SQLite we often need to get hold of the right DLL files for the given architecture and copy them to project’s output folder. But how to do it in an easy way? Pre-build event¬†commands give us the answer.

First, you will want to create a folder for the library you want to copy and create subfolders for each architecture you need. In each of those folders just place all the DLLs and supporting files you need to copy.

sqlite

Now right-click your Visual Studio project’s node in Solution Explorer, select Properties and then Build Events tab in the left pane. You will be presented with two empty boxes. In these boxes you can enter any commands that you want to execute before the project is built or after it is built, respectively.

Build

Now, click the Edit Pre-build … button you are ready to enter your desired command. We can use the simple command line tool xcopy to copy the files from our library folder to the output directory:

To explain what is going on here. The¬†Xcopy tool has two¬†main parameters –¬†copy source and copy target. My sqlite folder is placed in a libs folder that is one level up from my project’s main directory (which is denoted by the “$(ProjectDir)”¬†string)¬†– hence I first navigate to parent folder by “..\” sequence and then to “libs\sqlite\” here I need to enter the correct subfolder for the current project architecture. We can get the “x64”, “x86”,¬†or other current platform name¬†using “$(PlatformName)” macro. Now finally in this folder I use an asterisk (“*”) to instruct xcopy to copy all files in the folder. The target directory for the build is specified by the “$(TargetDir)” macro and I also give two additional options “/E” (to include subfolders in the copying process) and “/Y” (to always overwrite existing files in the target directory).

Now along with each build action, our command will run and the files we need will be copied to the project’s target directory as we wanted. Simple enough, but saves a lot of manual labor.

Accent color in Windows 10 app taskbar icons

The latest Technical preview builds of Windows 10 (build 10547 onwards) received a very interesting treatment for taskbar app icons of several built-in apps like Store, Outlook Mail, Outlook Calendar or Photos app. If you look closely, you can see that not only are the app icons without any coloful square outline (as default for WinRT apps), but they also have several areas filled by the system’s accent color.

ColorizedColorizedBlue

I was wondering how this can be achieved. The transparent color is used to make the “transparent” portions of the icon, but the colored fill? I thought that it must be some kind of “default” color that will be replaced by accent color. And as it turned out, I was right!
PhotosAppIcon

If you look at the app assets of the Photos app, you can see a surprisingly large number of different icons for “AppList” or Square 44×44 logo. The normal icons for this kind of icon with appropriate scaling are there, but we can also are the ones with “.targetsize-{size}” suffix. These are offered for entry only for four different sizes – 256, 48, 24 and 16 in Visual Studio. But you can apparently offer the system much more resolutions for even more granular scaling – 100, 96, 80, 64, 40, 32 or 20.

But this is where things get even more interesting! There are more different suffixes the Photos app uses!

  • contrast-black_targetsize-{size} – white and transparent icon (for high-contrast accessibility setting)
  • contrast-white_targetsize-{size} – black and transparent icon (for high-contrast accessibility setting)
  • targetsize-{size}_altform-colorize – accent color colorized app icon for taskbar, this is what we are looking for!
  • targetsize-{size}_altform-unplated_contrast-white – app icon for taskbar with transparency for high-contrast
  • targetsize-{size}_altform-unplated – app icon for taskbar with transparency
  • targetsize-{size}_altform-fullcolor – icons used in File Explorer for associated files, this is a full-colored icon

This is a lot of undocumented file suffixes ūüôā . But the one we are interested here is targetsize-{size}_altform-colorize . This image contains transparent portions for areas of the icon, that are … well, transparent, any other colors for areas that are visible and finally full black areas for those parts that should be replaced by the system’s accent color!

Although the official resources and documentation is so far quite lacking, any developer can use these special icon types in their app right now. Just include the surplus images with the correct naming (same as Square 44×44 Logo) in your app’s assets and all will work as expected. This gives quite a big creative opportunities for developers to make their app look even more alive on Windows 10.

Sample project

You can download a sample project with colorized taskbar icon here. The project is basically the default blank Windows 10 application with just one additional image file in the Assets folder – Square44x44Logo.targetsize-64_altform-colorize.png. This one file does all the magic! Once you run the application, indeed – you will find yourself looking at a very nice colorized application icon on your taskbar. And once you change the system theme, the icon will change as well ūüôā .

Square44x44Logo.targetsize-64_altform-colorize

A Developer’s Guide to Windows 10

Now is the best time to learn Windows 10 development!

Microsoft has released an updated version of their developer’s guide to the new Universal Windows Platform for Windows 10 on Microsoft Virtual Academy. Featuring¬†Andy Wigley¬†and Shen Chauhan , this tutorial will walk you through everything new in the Windows 10 development world and will show off the “RTM” developer tools (which is a misnomer, because there is now nothing as RTM with Windows as a Service and¬†build 10240 is just the first public release of Windows 10).

The guide covers everything from the basics of the platform itself, through XAML controls, adaptive layout and code, down to the nitty-gritty details and advanced techniques like¬†the concept of “App services”.

So jump in and get your first-hand experience with Universal Windows Platform!