Category Archives: Development


Floating header TextBox for UWP apps

Inspired by Greg Shacles’ FloatLabeledEntry I wanted to see how easy (or hard) it was to bring similar effect to UWP apps. This is the result:

Floating TextBox Header

Flying TextBox Header

TextBox already has a header in its template which is always shown. This helps us and we don’t have to create custom control, we can just alter the default style. For the above effect, the header had to be hidden by default and shown once user starts typing. This can be done easily just by changing the animations in the visual states. We will change the default template for TextBox which can be easily extracted in Visual Studio.

First, change the HeaderContentPresenter by setting the opacity to 0 and add RenderTransform.

	<TranslateTransform Y="25" />

Now, we want to animate header once the user starts typing. To do that, edit the Focused visual state and add the following animation:

<DoubleAnimation Storyboard.TargetName="HeaderContentPresenter"
				 To="1" Duration="0:0:0.25"
<DoubleAnimation Storyboard.TargetName="HeaderContentPresenter"
				 To="0" Duration="0:0:0.25"
		<SineEase EasingMode="EaseOut" />

And since we want the animation to reverse when the focus is lost, we should add transitions:

	<VisualTransition From="Focused"

And we are done. This is rather simplistic approach and we still need to tweak font properties a bit, maybe animate placeholder text as well. But that is left as an exercise for the reader. You can find the full code for the final style in gist


Scripting with Roslyn: Introduction

One of the best features that come with the brand new compiler API-s for C# and VB.NET is the scripting support. While not in its final form, it’s already quite usable. So let’s see it in action.

First, pull the latest sources from the official Roslyn repository and build them. The binaries should be in Binaries/Debug.

Next, open Visual Studio and create a simple Console application using .NET 4.6. Add references to the following dlls:

  • Microsoft.CodeAnalysis.Scripting.CSharp.dll
  • Microsoft.CodeAnalysis.Scripting.dll
  • Microsoft.CodeAnalysis.CSharp.dll
  • Microsoft.CodeAnalysis.dll
  • System.Reflection.Metadata.dll

The following code will create a new script with the code “Hello World”, evaluate it asynchronously and write out the result.

var script = CSharpScript.Create("\"Hello world\"");
var result = script.RunAsync();

	.ContinueWith(t =>


This is a simple as it gets. In our next post we’ll build a simple REPL :)

Get the source here.


Why Xamarin is actually native coding

Xamarin.Forms are awesome for building applications, but eventually you have to get dirty and fix platform specific issues. And once down there, one quickly realizes that native development is not so much different than native development for that platform itself.

Let’s take a look at the relatively simple problem with iOS: changing the unselected color for the tab bar icons. Searching the web brings us to the den of programming solutions, Stack Overflow, with the following solution The code is straightforward:

UIColor * unselectedColor = [UIColor colorWithRed:184/255.0f green:224/255.0f blue:242/255.0f alpha:1.0f];
item.image = [[item.selectedImage imageWithColor:unselectedColor] imageWithRenderingMode:UIImageRenderingModeAlwaysOriginal];

read more »

Tips Windows 8 Windows Phone

Dependency property registration helper

Update: the code was updated to support two additional scenarios: inherited classes and classes that cannot inherit DependencyObject<T>.

Writing dependency properties for XAML controls is annoying and contains some redundant parts. Let’s take a look at an example dependency property (generated from snippet):

public static readonly DependencyProperty PropertyTypeProperty = DependencyProperty.Register(
    "PropertyType", typeof (propertyType), typeof (SampleDependencyObject), new PropertyMetadata(default(propertyType)));

public propertyType PropertyType
    get { return (propertyType) GetValue(PropertyTypeProperty); }
    set { SetValue(PropertyTypeProperty, value); }

While the property (at the bottom) itself cannot be simplified anymore, the registration part at the top can be simplified quite a lot. Let’s take a closer look at the necessary parameters:

  • First is the property name which one should never write in string literals. The new feature in C# 6: nameof will help fix that, but for now we are stuck with this.
  • The second parameter is the type of our property, which is already written below and should somehow be inferred automatically. Reflection could help with that, but it’s a heavy artillery and is not an ideal solution here.
  • The third parameter is the type of the enclosing class, a context sensitive information that should be omitted.
  • Finally, in most cases the default value is the default value for the property type.

Our goal here is to remove redundancy, use contextual information and remove string literals all in once. And to shorten our code, of course. Luckily, we can already do that in C# 5 without the upcoming nameof feature and the final syntax for the registration part (the property, unfortunately, stays the same) can be reduced to this:

public static readonly DependencyProperty SampleProperty = Register(d => d.Sample);

read more »


C# 6.0 is here and will shorten your code

In case you haven’t heard the news, the new version of Visual Studio is out: Visual Studio 2015 Preview. You can grab it here. With you’ll get:

  • A new version of C# language currently at version 6
  • .NET Compiler Platform formerly known as Roslyn: the new compiler for C# and VB.NET which is open source and exposes quite a lot of the underlying infrastructure for the user
  • New JIT compiler i.e. RyuJIT which is also open source
  • Open source subset of .NET Framework

Small things really :) This post will focus on the new features in C# 6 which can both shorten your code and make it more understandable. So let’s begin. In fact, only a couple of new features can be used to add more code to your existing code base.

Class properties enhancements

Writing immutable classes is relatively hard in C# and a few small additions to the language make things easier. Take a look at the following class: read more »


XNA and Visual Studio 2013

This is definitely the coolest thing I found today: running XNA in Visual Studio 2013. Thanks to the unofficial contribution, it is possible to use XNA 4.0 in Visual Studio 2013, 2012 and 2010. Find the appropriate download links at codeplex.

This brings XNA development back in the latest version of Visual Studio, but sadly, although you can develop Windows Phone 7 XNA games in VS 2013, you cannot deploy them from Visual Studio since it doesn’t support WP 7. But that can be fixed since the final XAP is valid and XapDeploy can be used to deploy built games to emulator.

XNA 4.0 running from Visual Studio 2013

XNA 4.0 running from Visual Studio 2013

So as XNA projects can be loaded in the same solution as MonoGame projects, porting old games will be easier. Since the project promises porting XNA to DirectX 11, we now have two projects with same scope in mind.


Cool feature in C# vNext – default values for automatic properties

The next release of C# is on its way and brings cool new features. One very popular request is the ability to initialize automatic properties, those without an explicit backing field, to some value without resorting to constructor. You could vote on the UserVoice here. Here is the proposed syntax:

public int X { get; set; } = x;

And if you need readonly properties:

public int Y { get; } = y;

Although a small change, this can clear up the code significantly.

Windows Phone

Simulating click event on ApplicationBarIconButton

TL;DR it cannot be done. But, if you have access to the application’s source code, there is a small workaround.

So, why would we want that in the first place? UI automation is not as uncommon as one would think. Its primary use is for creating UI tests for which you need the ability to simulate clicks.

So, how does one simulate click on UI elements? By using a derived class from System.Windows.Automation.Peers.AutomationPeer.

But there is no such class for ApplicationBarIconButton and there is no way for us to manually invoke click events. Usually we could use reflection for this purpose, but platform security forbids us from accessing private methods and fields so that goes out of the window.

Luckily, we can create our own class that inherits ApplicationBarIconButton and exposes such function. It is pretty short code to write actually:

public class ApplicationBarIconButton : ApplicationBarIconButton
    public new event EventHandler Click;

    public void RaiseClick()
        if (Click != null)
            Click(this, EventArgs.Empty);

And that’s it, just replace every regular ApplicationBarIconButton with this in XAML and you are done. In your testing framework find buttons, cast them to this type and call RaiseClick.

Note that this won’t actually work if you are using some bindable replacement for the regular binding-unfriendly


Windows Phone

Nokia Imaging and Big UI Wiki Competition entry: Advanced Techniques for Big UI

I wrote about some advanced techniques for adapting Windows Phone UI for big screens and 1080p resolutions on Nokia’s Developer Wiki: Advanced Techniques for Big UI. The article was written as a part of Nokia Imaging and Big UI Wiki Competition 2013Q4 which ended two days ago. There are great entries in this competition and I recommend reading them if you want to become familiar with Nokia Imaging SDK 1.0 and developing applications for the big screen.

Here is an introduction:

Designing applications for Windows Phone 7.x (from now on WP7) was easy since there was only one supported resolution – 480 x 800 (WVGA). In addition, screen sizes did not vary that much between vendors. This “un-fragmentation” was hailed as a great feature for the young OS since applications would look the same on all devices that ran Windows Phone 7.

Windows Phone 8 introduced two additional resolutions: 768 x 1280 (WXGA) and 720 x 1280 (720p). The first is an up-scaled version of the original resolution and they share the same aspect ratio (15:9). The latter resolution actually has a different aspect ratio (16:9). This meant that applications had some extra space at the bottom for the UI, but in general if layout is done dynamically, UI does not need to be altered significantly to account for the extra space. The devices got a little larger, but this also meant little to the application design process.

However, coming with GDR3 update, Windows Phone 8 got a new resolution – 1080p. Along with the new, and currently the highest available, resolution, devices also grew in size. For the first time Windows Phone 8 is ran on devices with 6 in screen diagonal. Applications can no longer simply scale up to accommodate such large devices, they need to change their layout a bit as well.

This article presents a couple ideas for adapting the application’s UI for the large screen. It also contains some helper classes useful for detecting current resolution and current screen size. There is also a small trick used here to use 720p emulator image as a 1080p device with “faked” screen diagonal of 6. This allows for easy testing of mentioned techniques without having a physical device with either 6 screen diagonal or 1080p resolution.

Read more on wiki page.

Tips Windows Phone

Windows Phone UI Tip – Empty List Header Style

I’ve already talked about creating a so-called “empty list box template” for situations when you have no items and an empty screen area might confuse users. You could fake it by adding a little TextBlock control that would be shown when you have an empty ListBox control to tell the user that (s)he would normally have a list of items there.

To do that, I blogged about two different techniques: ListBox empty template – using visual states (part 1) and ListBox empty template – using control templates and behaviors (part 2).

One thing I haven’t talked about before is what should that text look like. In my opinion, unless you are completely reinventing your UI, you should strive for consistency. The best way to do that is mimicking the built-in apps. You already have such style in the stock applications: e.g. if you open Marketplace and search for some non-existing application, you will get the message that there are no such applications as you can see below. If you want to use exactly that style, you can use a predefined style called EmptyListHeaderStyle:

<TextBlock Style="{StaticResource EmptyListHeaderStyle}"
           Text="Some items should appear here..." />
Simple style for the "no results found" text

Simple style for the “no results found” text

If you are still targeting Windows Phone 7, you won’t be able to use that style because it was introduced in Windows Phone 8. But if you still want to use it, copy/paste the following style definitions in your favorite place for styles:

<System:Double x:Key="EmptyListHeaderFontSize">32</System:Double>

<Style x:Key="EmptyListHeaderStyle" TargetType="TextBlock" BasedOn="{StaticResource PhoneTextBlockBase}">
  <Setter Property="FontFamily" Value="{StaticResource PhoneFontFamilySemiLight}"/>
  <Setter Property="FontSize" Value="{StaticResource EmptyListHeaderFontSize}"/>
  <Setter Property="Foreground" Value="{StaticResource PhoneSubtleBrush}"/>

UPDATE: Please not that Windows Phone 7 does not have PhoneTextMidContrastColor, but PhoneSubtleBrush is close enough. It matches the dark theme version exactly, but is slightly different in the light theme.