Category Archives: Uncategorized

How to stop Facebook from stealing your attention

There are times when you check Facebook to just fill a free minute or post something and then you find you’ve been pulled into the vortex of links worth clicking. You can unfollow everyone and everything until your timeline slows down, but then they give you trending topics, suggested pages, ads etc. Well, today you can switch your Facebook from looking like this:
Continue reading

Tagged , , , ,

The Elusive ArgumentException in a List Control…

The last week or so I have been struggling with a bug that was keeping me away from updating WinRT XAML Toolkit. After adding an ItemTemplateSelector for my custom ListBox – I started getting ArgumentExceptions with a vague “Value does not fall within the expected range.” message and of course none of my code on the stack. At first I thought my custom ListBox subclass was causing some problems that the platform couldn’t handle, but then after replacing it with a regular ListBox it kept happening. Finally I noticed that replacing the DataTemplate I was using with another one that was simpler stopped the exception. Then I modified that template to look the same as the one I wanted to use – and it still worked fine! It took me probably 2 minutes of playing spot the difference to notice that the bad template had a DataTemplate inside of the DataTemplate! That obviously doesn’t generate a good list item! Hopefully this post helps someone working with a ListBox, ListView or GridView and getting these ArgumentExceptions that crash the app with no details of where they come from…

Tagged ,

Switching Project Type Between Windows Runtime Component and (.NET) Class Library

There are times when you might want to switch the type of your library between a Windows Runtime Component and (.NET) Class Library. Why would you do that? There are slight differences between these – a WinRT Component can be used by other assemblies written in any language supported by WinRT – your APIs will be projected to these other languages. A Class Library can only (easily) be used by .NET assemblies, but allows you to have class inheritance. Depending on the realization or change of your requirements then you might decide that you need to change the type of the library you have already created, but how do you do that? Easily. Assuming your code is compliant with the above mentioned limitations you just need to change the value of one XML element in your csproj file between <OutputType>winmdobj</OutputType> and <OutputType>Library</OutputType>.


Silly me, how could I have overlooked it? The project properties panel has an option for switching between Class Library, WinRT Component and Windows Store App!

Switching project types between Class Library, Windows Runtime Component and Windows Store App in Visual Studio

Switching project types between Class Library, Windows Runtime Component and Windows Store App in Visual Studio

Code Snippets – Disable Warning 4014

I use code snippets extensively. I don’t think it makes sense to do without them if you do any XAML work, though what you use them for is actually the code behind where lots of boilerplate code is necessary. My snippets collection consists mostly of modified Dr WPF’s dependency property snippets and various types of observable property snippets. Today I am working on cleaning up some code in WinRT XAML Toolkit and decided a snippet to disable warnings could be helpful, so here it is (also added to my collection on dropbox). Just use the sw shortcut for this Suppress Warning snippet.

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="">
  <CodeSnippet Format="1.0.0">
      <Title>Suppress Warning</Title>
      <Description>Surrounds with a #pragma warning disable/restore block.</Description>
      <Author>Filip Skakun</Author>
          <ToolTip>Comma separated warning list.</ToolTip>
      <Code Language="csharp">
        <![CDATA[#pragma warning disable $warninglist$
#pragma warning restore $warninglist$]]>

Minimalistic MVVM for Windows Runtime XAML Platform Development with C#

I have been using MVVM for a few years now and always felt it needed a summary of the state of things as well as my own opinion about it. This is it today. My approach to MVVM has been changing from the time when I was an eager student, through a devoted disciple, till today when I see it as a small tool in the toolbox of a XAML developer.

The original article has been republished by Safari Books Online.


The Model View View Model (MVVM) pattern is an architectural pattern used for separation of concerns in applications. It is popular in Microsoft’s XAML-based UI frameworks such as WPF, Silverlight or WinRT/XAML.

The MVVM architecture consists of the View layer (the UI design implementation), the View Model layer that provides bindable properties and commands to the view and the Model layer that contains the application’s actual domain model and business logic. The connection between these layers is such that the view model knows nothing about the view (it does not reference it) and the model knows nothing about either of the other two layers.

The qualities of an application architected based on the MVVM pattern are

  • Maintainability – separation of concerns and loose coupling helps modify one layer without affecting the other layers
  • Testability – being able to replace the view as well as view model with a test fixture allows to test the layers separately and avoid having to use unreliable and hard to maintain UI automation for all tests. That also helps overall maintainability of the code, since a change can be made in one part of code while tests reduce the risk of regressions in other areas.
  • Blendability – view models can fairly easily be replaced with design-time data and logic, so designers can create the views using Blend independently of other development work.
  • Ability to split work among multiple developers – not only the views can be implemented by designers or integrators, but also view models can be created separately from the models by mocking the models.
  • Portability – the view models and models can theoretically be reused in versions of the same app for different platforms.

MVVM was made possible in WPF – the original XAML framework thanks to the XAML layer that is the declarative description of the view as well as bindings – that allow to declaratively specify which properties of the view model are displayed or manipulated by the view, and commands that allow to represent actions executed by the view model in form of bindable properties. However, anyone trying MVVM for the first time soon notices problems with MVVM, such as

  • What are commands and why should I use them?
  • What gets created first – the view or the view model and how to connect the two?
  • Animations – how to trigger an animation from the view model or do something when an animation completes?
  • Navigation and dialogs – where to initiate navigation and dialogs – from the views or the view models?
  • State persistence – while saving the state of the application was a nice feature in the past – it is virtually required on modern platforms such as Windows Phone or Windows 8 – how to store and restore the state of the view and the view model though?
  • Non-bindable properties – a lot of the properties in the UI frameworks are not bindable, such as grid column and row definitions, Windows Phone application bar or in many cases – the style setter values.
  • Bindable properties are rather verbose – instead of using auto properties – even for the most basic bindable properties you need to invoke property change notification events.

The languages and the UI frameworks lack built-in solutions to these problems, so the developer community has responded with many frameworks that try to address these issues. Some of the more known libraries maintained by known experts in the XAML community are

  • MVVM Light Toolkit (by Laurent Bugnion) – most popular possibly because it really is pretty lightweight with just the basics of MVVM covered and the source code is easy to understand. For all platforms.
  • Caliburn.Micro (by Rob Eisenberg) – a bit more complicated, but supports convention-based approach where bindings are not explicitly specified and XAML is kept eerily clean. For all platforms.
  • Prism (by Microsoft patterns & practices team) – official guidance from Microsoft for developing composite applications with WPF, Silverlight and Windows Phone.
  • WPF Application Framework (WAF) – a popular, WPF specific library
  • ReactiveUI (by Paul Betts) – based on Reactive Extensions – a bit exotic part of the .NET framework that is well suited for highly asynchronous applications. For all platforms.
  • Cinch (by Sacha Barber) – a “Rich Full Featured WPF/SL MVVM Framework”.
  • nRoute (by Rishi Oberoi) – a big library with a lot of features, available for all XAML platforms.
  • Catel (by Geert van Horrik) – another rich framework with MVVM support with support for all platforms.
  • MVVM Foundation (by Josh Smith) – one of the early MVVM frameworks for WPF by an early MVVM advocate. Worth checking due to its small size and simple project structure.
  • Jounce (by Jeremy Likness) – “Silverlight MVVM + MEF Framework”.
  • Calcium (by Daniel Vaughan) – composite application toolset for WPF/Windows Phone.

Over the years MVVM Light, Caliburn.Micro and Prism have grown to be the three most popular frameworks with the biggest communities around them and are the best choices to start with, though the other libraries have interesting features that are worth checking too.

MVVM for WinRT

What is changing with Windows 8 for MVVM development? Well, Windows Runtime or WinRT is the new default Windows API and the most popular MVVM frameworks are seeing gradual updates to support Jupiter – WinRT’s version of a XAML UI framework. They are however still mostly .NET class libraries – not usable in C++ or Javascript. Right – Windows 8 also enables XAML development with C++ and MVVM is supported there too. Using Javascript with HTML is another option and you can also use MVVM there using the KnockoutJS library. You can then develop WinRT applications in C#, Visual Basic, C++ or Javascript and implement the MVVM pattern in any of these languages. Back to C# and .NET though – if this is the platform you choose – there are some changes coming there that affect how you can implement MVVM like the new CallerMemberAttribute in C# 5.0, but the one I would like to talk about is the BindableBase class that comes standard with multiple Visual Studio project or item templates. Since we now have a base view model class available to people who might not have even heard of MVVM before – this might become a pretty popular class used by C# developers building apps for the Windows Store. You now get a pretty good view model base class out of the box.

Should you use the BindableBase class and is it enough to build MVVM-based applications?

I still do recommend using MVVM Light Toolkit or Caliburn.Micro for larger projects, since they provide features that you will most likely need sooner or later as your application grows and if you want to keep it implemented in clean MVVM fashion, however over the years as these libraries have grown in popularity, they have also grown in features and the built-in cross-platform support, made them more complicated and harder to study. Sure – with NuGet you can now have the latest version of MVVM Light referenced by your project within a few clicks, but then you cannot see the source code and it is harder to figure out how it works or how to use it, especially with the growing number of APIs available.

For smaller projects – the BindableBase from the Visual Studio templates might just be enough. Though a snippet for observable properties as the “pp” snippet in my snippets helps a lot (just install the snippets and type pp[TAB] to insert an observable property in your view model). Commands? Do you really need them to implement the MVVM pattern? A regular public method on the view model works just as well and if you need to disable or enable a button based on whether a method can be executed – a regular observable property like “CanExecuteMyMethod” works just as well as a CanExecute method of a command. By the way – if you really want to – you can still create any MyCommand class that implements an ICommand interface – it is not that much more code than using a DelegateCommand/RelayCommand of Prism/MVVM Light, though admittedly these do make it a lot easier to inline its implementation.

Not using a third party MVVM helper library has many benefits – no need to install anything, no dependencies, no reliance on reflection, no dead code in form of unused framework APIs, no need to justify using open source code at companies that do not generally allow it. It is just what you get with the standard templates.

Of course these existing libraries have custom solutions to some specific problems and provide generic solutions to others, but usually eventually you stumble upon something that the library you chose just does not solve. In such cases I sometimes build my own reusable libraries or controls or just write some one-off piece of code that glues MVVM together. If the problem you need solved involves some custom interaction logic – you are going to be better off implementing a custom control or attached behavior than trying to stuff everything in the view model.


Ultimately using code behind is an easiest choice and does not invalidate MVVM. Experts in the field such as Laurent Bugnion have long been saying that MVVM is just a pattern and you should not be afraid of using code behind in your applications. However religiously it seems to be treated by many developers – if you just start by using view models to drive your views – it is enough to reap most of the benefits of the pattern and will help you create a maintainable application. Unless you are building a big line of business application, planning on unit testing your complicated view model logic or doing a lot of UI development using Blend – you might not need a fully separated view and view model. If you are working on a big project though, or your project just grows big – you might consider one of the popular frameworks or building your own. At some point you will just find that you can’t live without a pub-sub implementation like MVVM Light’s Messenger or Prism’s EventAggregator, you will want to write unit tests and find a need for an IoC container, so you can mock and shuffle your components., you will want to bind everything even if Microsoft’s does not support the binding you want. Until then though – feel free to start small and lean and worry about features rather than patterns. MVVM is just one of the tools to build an app and you might find that learning about custom layout logic, touch interaction, custom controls or behaviors is going to benefit you more than wondering which MVVM framework to use.

I just sliced 262 fruits, including 19 delicious apples on Fruit Ninja for Windows!

Fruit Ninja

I just sliced 262 fruits,…

I just sliced 123 fruits, including 7 delicious bananas on Fruit Ninja for Windows!

Fruit Ninja

I just sliced 123 fruits,…

WinRT/Metro Style App Data

I was trying to find out where the WinRT apps files are stored and found 3 locations. Not sure how much benefit would be in digging deeper, but this could help in debugging your or reverse engineering someone else’s applications…

Continue reading

Tagged ,

Windows Developer Camp – March-June 2012, USA, Multiple locations

I found multiple (21) free full day training sessions for Windows 8 developers – here.

A path from C/C++ to C# and back to C++

About ten years ago I started my first full time programming job. I was working on some business software written in C/C++. I say C/C++ instead of just C++ because it was written mostly in C with classes – with perhaps a few cases of inheritance or actually even only few classes – it used structs in many places to group some methods together the same way you would use classes today. The code was fairly complicated and it was just aging. The standard C libraries it used were not very rich, so if you wanted to code up something fairly straightforward – you had to dig through a lot of documentation looking for something basic only to end up implementing that list class yourself. We were using a Watcom compiler at that time and trying out Borland C++ Builder for some side projects showed it was a great improvement in that VCL provided a lot of great wrapper classes for Windows APIs making things easier. Two years later we were looking into rewriting our application or at least starting a new version and considering which tools to use – basically trying to choose between Borland C++ and C#. I was on the C++ side – it was a fairly known language, more predictable and providing intuitively higher performance, while C# was at version 1.1 and had lots of great libraries, but a bit foreign and why would anyone want to go away from the fun of using pointers, managing object lifetimes and relying on some garbage (collector)? Well, I lost – Microsoft seemed to be focusing on supporting C# and in the end it turned out to be a lot more productive than C++.

Fast forward 8 years and Microsoft says – in Windows 8 you can code using C#/VB, JavaScript or C++. Well, the word on the street is that it is so that programmers fluent in any of these languages will be able to code applications for Windows, so I guess I will stick with C#. Maybe I will look at HTML5, JS and CSS, since these seem to be getting most traction, I thought. Now, having found some limitations in the .NET/WinRT stack I have a feeling like the C++/DirectX route is the most attractive. The .NET stack might make you more productive than the JS or C++ – especially if you have been coding in C# for the last eight years and perhaps HTML5 has better graphics performance or some other interesting features, but it feels like learning C++/DirectX on top of C#/WinRT is what would allow me to cover most scenarios for writing Metro Style Apps™, so especially with some experience working on the test team for the DirectX wrappers in the Windows API Code Pack – I am hoping to have an easier start in diversifying my skills.

Continue reading

Tagged , , , , , ,