Custom window movement and resize in WPF

Windows can be moved on the screen by dragging their title bar; they can be resized by dragging their borders. But what if our window needs no title bar / borders (or they are custom drawn)? (aka WindowStyle="None").

Introducing MoveResizeBehavior, a WPF custom behavior that can be added to any FrameworkElement will provide move and resize functionality for its parent window.

<Border DockPanel.Dock="Top" Height="11" Margin="7"
        b:MoveResizeBehaviour.ResizeWindow="Top"/>
<Border DockPanel.Dock="Bottom" Height="11" Margin="7" 
        b:MoveResizeBehaviour.ResizeWindow="Bottom"/>
<Border DockPanel.Dock="Right" Width="11" Margin="7,0" 
        b:MoveResizeBehaviour.ResizeWindow="Right"/>
<Border DockPanel.Dock="Left" Width="11" Margin="7,0" 
        b:MoveResizeBehaviour.ResizeWindow="Left"/>
<Border Height="43" VerticalAlignment="Top" 
        b:MoveResizeBehaviour.MoveWindow="True"/>

where

xmlns:b="clr-namespace:AndreiPana.WPF.Utilities"

ResizeWindow can take one of the following values: None, Left, TopLeft, Top, TopRight, Right, BottomRight, Bottom, BottomLeft, while the MoveWindow can be either True or False.

Internally, the behaviors attach to the MouseDown event, so the FrameworkElements on which they will be set better not process themselves MouseDown, otherwise it might interfere with the behaviors.

A simple and small test project showing the functionality is available on Github but, for convenience, here’s the MoveResizeBehavior.cs file that you can copy/paste to any WPF project and used it as it is:

VisualStudio Output Window Error highlighter

In Visual Studio 2015, the Output Window contains plain text, with no colorizing or highlighting of any kind. This makes it hard to spot some errors in the multitude of output text, for example WPF’s binding errors.

I have long wanted an extension to highlight this kind of errors, so I decided to write one for myself. Very simple, it just puts in red all the lines containing “Error” so that now I can see if I miss any binding error in WPF, definitely saving me a lot of time.

OutputColorizerVSX_Screenshot

Download the extension:

Xaml design-time DataContext

System.Windows.Data Error: 40 : BindingExpression path error: 'Emial' property not found on 'object' ''Customer' (HashCode=49475561)'. BindingExpression:Path=Emial; DataItem='Customer' (HashCode=49475561); target element is 'Label' (Name=''); target property is 'Content' (type 'Object')

This is one of the most frustrating binding errors that happen while writing bindings in xaml. Sometimes, if not careful enough, it might easily get lost in the Visual Studio output window. To reduce the number of such errors and to design the UI more easily, one may benefit of the support of auto-completion while writing xaml bindings in Visual Studio.

To add a design time DataContext:

<Window x:Class="Sample.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:vm="clr-namespace:Sample.ViewModels"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        Title="MainWindow" Height="350" Width="525"
        mc:Ignorable="d"
        d:DataContext="{d:DesignInstance Type=vm:Customer, IsDesignTimeCreatable=True}">
    <Grid>
        <StackPanel>
            <Label Content="{Binding Emial}" />
        </StackPanel>
    </Grid>
</Window>

Lines 6 and 9 are the ones that do the trick. The Visual Studio designer will use this DataContext object at design time.
Lines 5 and 8 are also needed to instruct the real xaml compiler to ignore this DataContext attribute.

Although I didn’t find any official documentation over the DesignInstance, this extension supports three parameters:

Type – this is the type of the object you want to use as a DataContext at design time (in my case here, I have a simple Customer view-model that has some Name, Address and Email properties).

IsDesignTimeCreatable – if this is true the designer will simply instantiate the type and use it; if it is  false the designer will generate a type with the same properties as the one specified and instantiate that type.

To be “design time creatable” the type must have a constructor with no parameters. If it has, the designer can instantiate it and use it. If the type does not have a default constructor, the designer doesn’t know what parameters to pass to the other constructors so here is where IsDesignTimeCreatable = false helps.

The drawback of using IsDesignTimeCreatable = false is that any properties set in the original type are not visible in the dummy type created and instantiated.

There are some workarounds for using IsDesignTimeCreatable = true like adding a parameterless constructor (perhaps in a derived class and using that class instead), but it all depends on the exact scenario.

CreateList – if true the designer will create a collection of your type and that can be used for bindings to the ItemsSource properties, for example or in another place where a collection is expected.

Now Intellisense shows auto-completion for DataContext members:

xaml-datacontext-designtime

Intellisense documentation for Unity3D API in Visual Studio

By default, Unity3D 4.6 does not ship with XML documentation for the Unity API, therefore Visual Studio is unable to display documentation in Intellisense.

To fix this, download the file UnityEngine.xml (right-click, Save As…) and copy it to the following Unity folder:

c:\Program Files (x86)\Unity\Editor\Data\Managed\

(Path may be different if Unity was installed in another location than the default one)

folder

Before:

after

After:

before

Note that administrator permission might be required to write to Program Files.

Observable Property C# code snippet

One of the VS functionality I abuse every day is writing code via the code snippets, those little fill-in code pieces that appear when you press tab twice after writing their mnemonic like propdp[Tab][Tab] for defining a DependencyProperty.

Unfortunately, VS doesn’t come with such a snippet for defining an observable property, which might be particular useful when working with MVVM or/and WPF, most likely because there is more than one way to implement such a property. However, I usually implement them in the same way, something like this:

private string _Name;
public string Name
{
    get { return _Name; }
    set
    {
        if (_Name != value)
        {
            _Name = value;
            RaisePropertyChanged("Name");
        }
    }
}

And the class implements INotifyPropertyChanged and RaisePropertyChanged looks like this:

public void RaisePropertyChanged(params string properties)
{
    var handler = PropertyChanged;
    if (handler != null)
        handler(this, new PropertyChangedEventArgs(prop));
}

In this conditions, when I have to write a lot of observable properties (actually I am using it even if I have to write only one such property), it comes very handy to have a code snippet that generates the property:

propo.snippet:

<?xml version="1.0" encoding="utf-8"?>
<CodeSnippets xmlns="http://schemas.microsoft.com/VisualStudio/2005/CodeSnippet">
  <CodeSnippet Format="1.0.0">
    <Header>
      <Title>Observable property</Title>
      <Description>Adds a new observable property to the current class.</Description>
      <Shortcut>propo</Shortcut>
    </Header>
    <Snippet>
      <Declarations>
        <Literal>
          <ID>Type</ID>
          <ToolTip>Replace with the type you want your property to have.</ToolTip>
          <Default>PropertyType</Default>
        </Literal>
        <Literal>
          <ID>Name</ID>
          <ToolTip>Replace with the name you want to give to the property.</ToolTip>
          <Default>PropertyName</Default>
        </Literal>
      </Declarations>
      <Code Language="CSharp">
        <![CDATA[private $Type$ _$Name$;
        public $Type$ $Name$
        {
            get { return _$Name$; }
            set
            {
                if (_$Name$ != value)
                {
                    _$Name$ = value;
                    RaisePropertyChanged("$Name$");
                }
            }
        }]]>
      </Code>
    </Snippet>
  </CodeSnippet>
</CodeSnippets>
To install this snippet, save the above xml in a file called propo.snippet and use the Import button in the Visual Studio’s Code Snippets Manager (Tools / Code Snippets Manager).
To use this snippet write propo in a cs file and hit Tab key twice.

Framework vs. library

Two software terms that programmers use every day. Yet, if you ask programmers what they are, you will most likely receive different answers from one programmer to another. I found out this the other days asking some of my colleagues and I then realized I have a personal definition for library and framework, which, of course, I consider to be the right definition.

For me, a library is a collection of methods and functions (and even classes or other more exotic structures) that help achieve a result, or solve a problem. The application calls the methods in the library to solve its tasks.
A framework, on the other hand, is the abstract structure of an application. To complete the application, the programmer adds code that customize this framework in such a manner that will solve the applications tasks. The framework calls this code when it needs. A framework typically already contains most or some of the logic and the structure of the application and some special points where custom code can be inserted in the default flow to alter it in order to achieve new functionality. Sometimes, framework are very complex and might include programming languages or compilers.
FWVSLIB2

 

And I think that if we look at some examples, the things become quite clear:
  • C Runtime Library – contains functions like sprintf that a programmer can call to format a string.
  • 7-zip compression library – contains functions that a programmer can call to compress or decompress files.
  • ASP.NET is a framework, because you only provide a few missing pieces to the barebone to have your web application.
  • Spring – a framework for Java applications. Again, the programmer just writes some of the missing pieces, the framework does the rest.

Book: Dependency Injection in .Net

Dependency Injection in .Net by Mark Seemann

I must say from the beginning, this is definitely one of the best book I’ve read about programming. I found the book written so well that I think Seemann reviewed the text at least a hundred times and fine tuned each phrase to obtain the perfect whole.
The thing I liked the most about the book was that the information was very well structured and presented in a very logical way. The second thing I liked it was the fact that once I started reading, I couldn’t let it off my hand until I read it all. And I like that on a book.
Going through the content, the book is made In Part 1, the author explains what DI is, why it is useful and shows some DI examples: a simple one first, but also a more complex one, because it is the complex and large projects where the DI becomes extremely helpful. Despite being complex, this second example is quite easy to understand because is constructed based on a (kind of) real life discussion between programmers.
Part 2 is all about how to do and how not to do DI. These are presented as patterns (constructor injection, property injection, method injection and ambient context injection) and anti-patterns (control freak, bastard injection, constrained construction and service locator – and I know there is an ongoing discussion here about the service locator being good or evil, but Seemann makes a pretty damn good point about it in the book).
Part 3 goes a step further and, in order to better assimilate the concepts, it shows how you can create your own DI container. This will guide the reader between all the aspects and the problems DI faces and explains how to address issues like object life time, object creation interception, cross cutting concerns, etc. There is also a chapter about object composition when working with some of the most important .Net technologies (ASP.NET, WPF, WCF).
In part 4, each chapter is dedicated to one of the most used DI containers: Castle Windsor, StructureMap, Spring.NET, AutoFac, MEF and Unity. These chapters are not detailed references about the containers, but are there more to give the reader a feel about how using one container or the other might be like.
Now that I showed a little bit what subject the book touches, I must say that I can’t emphasize enough how much I enjoyed the way in which this information was presented: simple, with reminders, with case studies, with well-made arguments.
I strongly recommend this book to every .Net developer, even to those who are already using one of the DI containers available for .Net; they will better understand the concepts and will find about alternatives to the container they are already using. And for those who never used DI before, this is definitely a must read. You will see programming a lot more different after reading it.