Help I have a control that is automatically getting scrolled to.. Is my WPF app haunted ?

Long has it been since I wrote a blog post on WPF. <excited> Today I found something that I had to share with you guys. It’s not some big WPF feature, rather its very very small and probably it serves only a case or 2 however if you are unaware of it, you can spend hours scratching your head trying to figure out what is happening in your UI.

The problem

Let me start by giving you some context on what was my issue. I had a ScrollViewer, inside it I had a bunch of A4 paper like rectangles, which I use to render different pages of a book. Each “rectangle” had an InkCanvas so that the user can annotate the papers. The ink is only enabled when the user presses on a button. The issue was that the scrollviewer would automatically scroll as soon as there is a mouse down. This happened all the time causing things to flicker when I have multiple pages visible on screen. What made this even worse is the fact that this happened as soon as the user was pressing down with the pen thus ink would end up everywhere =) yes it was as if the app is haunted

I started wondering why would this happen. I prematurely blamed the InkCanvas for this however when I switch it with something else it was still happening. I started investigating and I came across this StackOverFlow thread (kudos Andrew Smith always great insights on WPF).

Let’s understand why this happens

What happens is that OnGotFocus of a control BringIntoView is called. BringIntoView is a method inside FrameworkElement which will raise an event called RequestBringIntoView. This is an event which gets bubbled up the visual tree. Anyone can handle this event. In the case where you have a ScrollViewer as one of your ancestors, ScollViewer will call the MakeVisible method which will basically ask the layout panel to render the item in view.

postimage1

This is all fine and dandy however sometimes (such as my case) you want to disable this behavior since it can irritate the user (or in my case make a mess with Ink)

Solution

The solution is easy, don’t let the event reach the ScrollViewer. To do this you simple need to handle the event like you would with any other RoutedEvent. Consider the following XAML

<ScrollViewer Grid.Row="2">
    <ItemsControl ItemsSource="{Binding}" x:Name="List">
        <ItemsControl.ItemTemplate>
            <DataTemplate>
                <Button Width="200" Height="150" Background="{Binding Item2}">
                    
                    <TextBlock Text="{Binding Item1}" Foreground="White" FontSize="25" FontWeight="Bold" VerticalAlignment="Center" HorizontalAlignment="Center"/>
                    
                </Button>        
            </DataTemplate>
        </ItemsControl.ItemTemplate>
    </ItemsControl>
</ScrollViewer>

What you would do in this case is that you would handle the RequestBringIntoView of the ItemsControl (or any element whose ancestor is the scrollviewer, in this case it must be the ItemsControl) and set is handled to true. And voila. no more scrolling.

This might seem very small and useless however by knowing how this works you will avoid being in a position where you see a behavior and cannot explain it. I have attached a small code sample if you want to play around a bit more with this.

Download Sample Code

MVVM in the web world

Introduction

Lately I have been experimenting with some web and I must say. the web is really making really amazing advances. The JS libraries out there are pretty awesome and make your job much more fun that it was a couple of years back !

One library that really really impressed me is (no not JQuery even though I must say I am quite impressed with JQuery as well !!) Knockout.js. The idea behind Knockout.js is to introduce MVVM to the world of web… One might ask does it even make sense to introduce a pattern like MVVM, how will it work without data binding capabilities ?? Well easy, bake binding capabilities in the library Smile and that is what Knockout.js is all about.

I will not give a deep dive to knockout but I will just show some of the capabilities of this library and then explain why I see this library playing a big part of web development we know today.

Binding capabilities of Knockout

So for those that are used to XAML technologies binding is our bread and butter. You can databind to properties in the view model to any DependencyProperty in an element. With Knockout the same features are available… Lets have a look

Knockout as the awesome JS library that it is uses unobtrusive javascript which really means it uses attributes to specify behaviour thus if JS is not enabled, no big deal everything would render since browsers ignore attributes that they do not understand.

To set the datacontext you call ko.applyBindings(viewModel, domElement) the second parameter is optional and if you do not set it, binding will be applied to the root element (and yes binding works like DataContext in XAML its “inherited”.

To specify a binding you specify the data-bind attribute to the element and inside you specify the type of binding and to which property

image

There are many types of bindings (by type I mean the “text” in this case part of the binding). You can see the full list here.

As I said I am not going to do a deep dive since the documentation for knockout is pretty awesome but here are some highlights for those that are used to XAML binding.

In XAML we are used to convertors if for example we have a bool property and we want to control Visibility; in Knockout you just put the code there and then. If you want to bind to more that one property just seperate it with a comma Smile simple; easy; AWESOME

image

For example in the above snippet I am binding the css class to be negativeTextBid if the negative property is greater or equal to positive BUT if it is the other way round then I am setting positiveTextBig. And yea I am also binding the text to count property in the same line. Wuhu!! You can imagine what one can do with such binding capabilities!

Ok so cool what about updates, if I change a property in my ViewModel how do I push it to the UI. Well in XAML we have INotifyPropertyChanged in Knockout.js we have ko.observable();

image

An observable will do all the work of looking up who is referencing it and give it the update. One other really awesome thing that comes in Knockout is dependantObservable (or also known as computed properties). This is a property that has a function and the function depends on other observables thus when one of those observables changes also the computed property/ dependant observable will fire a notification to the UI.

image

For collections (i.e. INotifyCollectionChanged for those XAML guys reading) there is ko.observableArray();

Speaking of which.. So how would you leverage a ko.observableArray?

Is there something like ItemsControl?

hah of course… There is something called the foreach binding… you put it for a div and magic happens

image

What about DataTemplates like stuff? well Knockout can also be used with JQuery templates to do this sort of stuff. Read more here

Ok so hang on tight for some more coolness…

What about commanding

In XAML technologies we have command that would link for example a button click to some sort of action/functionality in the ViewModel. In knockout this is just a normal databing called the click binding. Read more here

image

and yes you can go beyond click. There is event binding, selectedOptions binding and many others…

So why would you want to have ViewModels in javascript?

Well today’s web is quite complex and having code running around, manipulating DOM elements after getting responses from AJAX calls can become one giant nightmare. By having a “UI layer” that separates the concerns where the HTML is your presentation and the viewModels in Javascript are the facilitators for the presentation data, then have a binding mechanism that glues the 2 together; is really a dream come true. Thank you Knockout!

One must understand that Javascript of 2012 is not the same as we know it a couple of years back where it was really a scripting language to do small things that you could not do declaratively in html. With the introduction of AJAX Javascript started growing and growing into a full fledge language that many today work with everyday to build compelling web applications. So YES you must ensure that you apply the proper patterns even when doing Javascript! Fail to do so and you will get stuck in nightmares and hate the web with all your might !

Knockout really enables you to clean up your presentation layer and introduce MVVM to it. It does so by giving us Databinding capabilities and a whole bunch of utils to facilitate javascript development for the presentation layer.

If you did not try it already, I suggest you give it a shot!

Knockout you truly knocked me out !

MEFedMVVM NavigationExtension

Introduction

Most of the MEFedMVVM features so far were all around discoverability of ViewModels, yet when building MVVM application sometimes you want to also have a mechanism to discover and launch views. If we look at web development its all about resources sitting on a server and you can launch/load a specific resource via a URI (Unique Resource Identifier). This mechanism proved to be a very easy and scalable way of locating views and within a Web Page you can link to other pages very easily. When building WPF applications that are purely content based such a mechanism would really come in handy, and if you think about it MEFedMVVM is all about discoverability so why not support this scenario.

Since this is not really part of the core MEFedMVVM I created an extension that you can use to accomplish this, MEFedMVVM NavigationExtension.

MEFedMVVM.NavigationExtension support both WPF and Silverlight 4.

 

Enter MEFedMVVM Navigation Extensions

The idea is to be able to specify to a View that it can be located by a unique identifier (a string) and then you can have someway of launching that view and render it in some container/host. Something like this

image

And you make the view discoverable by decorating it with this attribute

image

As you can see in the figure above, there are 3 magic attached properties that are attached to the “Invoker”

  • NavigationExtensions.NavigateTo
    • Specify the unique identifier (string) to locate the view. I use a URI format but you can use whatever you like as long as its unique
  • NavigationExtensions.NavigationHost
    • Specify where you want the View to be rendered
  • NavigationExtensions.NavigationParameter
    • Specify a Parameter to be passed to the ViewModel of the View. The reason why the parameter is passed to its ViewModel is because if you are doing MVVM then your View has no need for parameters, its the ViewModel that needs the parameter(after all the ViewModel controls the logic). We will see how you can still cheat and do whatever you like at the end of the day, the parameter can be passed to the View.

So one might wonder how will my ViewModel receive the parameter. This is done by your ViewModel being set as DataContext of the View (if you are using MEFedMVVM to link the View to the ViewModel this happens automatically) and also your ViewModel has to implement the INavigationInfoSubscriber interface. This interface defines 1 method OnNavigationChanged which will pass along the parameter and also give you an instance of the INavigationManager responsible for starting the Navigation.

image

 

Recap

So till now we can

  1. Make a View discoverable by specifying a Unique Identifier
  2. Specify an Invoker and give it enough information on what to render and where to render it
  3. And also specify a parameter to be passed

This pretty much covers the bare basics, let’s get a better understanding of what is a Host and what is an Invoker before we deep dive in more complex scenarios.

 

Host and Invoker Deep Dive

When building the NavigationExtensions I wanted to make sure that you can create your own handlers both for Hosts and Invokers, and what is the best way to do so if not with MEF Smile

There are 2 base classes you need to write in order to create your own handlers.

  • ControlNavigationHost
    • This is to create your own hosting control. Out of the box you get one which is ContentControlNavigationHost (it handles any ContentControl)
  • ControlNavigationHandler
    • This is to create your own invoker for a control. Out of the box you get one which is the ButtonNavigationHandler (it handles any ButtonBase)

The ControlNavigationHost has 4 methods that you need to implement (all method implementation would be usually one liners)

image

In order to make your own ControlNavigationHost discoverable by the NavigationExtensions simple Export it like this

image

The ControlNavigationHandler has 3 methods you need to implement

image

In the implementation you simple have to register to the Event you want and then call the OnEventFired protected method of the base class. here is an example

image

And again to make the handler discoverable you Export it like so

image

Please note: that its up to you how you want the creation policy to be (i.e. If MEF should create a new instance of the NavigationHandler or not but in this case you should always make it NonShared so that for each invoker in your application you have a different ControlNavigationHandler instance)

Apps are usually more complicated, so let’s dive into more complicated scenarios

Before we start going through these scenarios let’s have a look at some interfaces and classes that MEFedMVVM exposes for you to consume/implement

INavigationManager 

image

INavigationManagerProvider

Implement this interface on a class that will be passed as NavigationParameter and you will get injected with a INavigationManager responsible for that Navigation

image

INavigationInfoSubscriber

Implement this interface in your ViewModel to get passed the NavigationParameter.

image

NavigationCommand<T>

A NavigationCommand is just a DelegateCommand<T> BUT it implements the INavigationManagerProvider interface. When used as a NavigationParameter it will hold the instance of the INavigationManager so that you can do things such as Closing a navigation. We will see the NavigationCommand<T> being used in the first scenario below.

 

Scenario 1

Let’s say you have a dialog that shows some settings and when you are done you want to get those settings back to the original ViewModel that “started” the navigation to the Settings screen. Here are a couple of screen shots for such a scenario.

image

In order to do this we need the MainViewModel to expose a NavigationCommand<T>

image

and the Execute handler for this would be something like this

image

We will revisit the code inside the Execute Handler in a bit**…

Now we can specify that the NavigationParameter is this command so that the SettingsViewModel can execute this command when it is done and give us the ApplicationSettings object instance.

image

The Settings ViewModel implements the INavigationInfoSubscriber thus it will get injected with the NavigationCommand that we are passing to it via the NavigationParameter attached property

image

Once the Settings ViewModel calls the Execute on the _onSettingChangedCommand it will invoke the method inside the MainViewModel (OnSettingChangedExecuted) passing the new ApplicationSettings.

**One thing to note is that the MainViewModel is also calling CloseNavigation on the NavigationManager of the NavigationCommand. This is so that as soon as its done applying the new settings the Settings screen disappears.

Download the sample and play around with it to get a better feel of how this all works together (its under Samples/TestNavigation)

Scenario 2

Let’s say you have a sort of Wizard Step by Step UI.

image

In this case we want to chain the Navigation so that the CreateUserProfileViewModel send the UserProfile not to the MainViewModel (the ViewModel that started the Navigation) but to the ViewModel next in the chain i.e. the RenderUserProfileViewModel.

In order to do so both “Invokers” (i.e. the button for the CreateUserProfile and the button for the RenderUserProfile) must have the same navigation “invoker”. You do so by explicitly setting the NavigationHander attached property (this is an attached property that exposes the Navigation handler for an “invoker”).

image

Ok so now we have both “invokers” using the same NavigationHandler; because of this we can register to the NavigatingAway event of the INavigationManager inside the CreateProfileViewModel and pass the data we want to the RenderUserProfileViewModel (which is the NewNavigationInfoSubsciber in the NavigationEventArgs passed by the event)

image

So basically the CreateUserProfileViewModel (Step 1) could pass along data to RenderUserProfileViewModel (Step 2) and you can continue chaining like this one step after another.

NOTE: For Silverlight you instead of using the NavigationExtensions.NavigationHandler use the NavigationExtensions.ChainToElement and specify the other button (this is because there are issues around binding to custom attached properties in SL). This approach can also be used in WPF.

image

 

Download the sample and play around with it to get a better feel of how this all works together (its under Samples/TestNavigation)

Conclusion

One thing I love about this Extension is that it enables you to use View-First approach to MVVM in nearly any scenario. Yes granted sometimes its better to have ViewModel-First approach but in my experience if you can always work using View-First life becomes much more easy because your code is more loosely coupled. In fact this is one of the things I love about MVC and Web in general… Controllers never reference each other, A View has a controller and thats it. In MVVM we tend to complicate things by having Parent ViewModels that have Child ViewModels yada yada yada… just my 2 cents…

This is all still work in progress, it needs more testing from my end to make sure there are no side effects such as memory leaks etc yet feel free to poke around and play around with it. As always feedback/bug reports are very welcome.

Download the code from http://mefedmvvm.codeplex.com/SourceControl/list/changesets

ICommand discovery with MEF

Sometimes you are in ViewModel X and you want to execute a command on ViewModel Y. You do not want to link the 2 because of some constrains that that might impose. How can you leverage MEFs capabilities to overcome such a situation?

Easy have the ViewModel Y expose the command as a property just like you would have it for binding from the View, but also add an Export attribute on the property and give it a name

image

 

Now from ViewModel X simple imports the ICommand by specifying that same name (yes you can have the string as a constant, also I would advice to use constants to avoid conflicts in strings)

image

 

MEF will automatically get the command from ViewModel Y into ViewModel X for you. This works very nicely with MEFedMVVM since MEFedMVVM resolves all ViewModels via MEF thus you do not need to do anything to resolve the ViewModel or anything. You simply decorate the properties for Export and Import and viola you can start drinking beer Smile

Happy coding Smile

MEFedMVVM with PRISM 4

Today I was looking at PRISM 4 and how it uses MEF as its DI Container and I thought, wouldn’t it be cool if you could use the 2 together?

Update: Please also check out this post to see how you can use the same composition container for both PRISM and MEFedMVVM so that stuff like IRegionManager, IEventAggregator etc can be injected also in MEFed ViewModels

http://mefedmvvm.codeplex.com/workitem/15391

Why would it be cool?

PRISM brings to the table

– Region Manager
– Modules infrastructure
– Many other utilities and services that you can consume

MEFedMVVM brings to the table

– ViewModel injection in XAML
– Design Time vs Runtime services (so that you can inject design time services when in blend)
– ContextAware services such as IVisualStateManager

Having the 2 working together would be awesome. The question is can they work together?

…teasing… suspense … ok enough Smile

The answer is yes and very easily…

How to do it

In PRISM you need to create a bootstrapper that will basically compose your application. MEFedMVVM also has a sort of Bootstrapper where you can specify how you want to compose the MEF composition. So as such all you need to do is to have your PRISM bootstrapper also tell MEFedMVVM how to do the composition.

Let’s start by creating a PRISM bootstrapper

We need a class that inherits from MefBootstrapper and we will need to override a couple of methods. Here is the code to do this

public class Bootstrapper : MefBootstrapper

{

    protected override void ConfigureAggregateCatalog()

    {

        this.AggregateCatalog.Catalogs.Add(new AssemblyCatalog(typeof(Bootstrapper).Assembly));

    }


    protected override void InitializeShell()

    {

        base.InitializeShell();


        Application.Current.MainWindow = (Shell)this.Shell;

        Application.Current.MainWindow.Show();

    }


    #region Overrides of Bootstrapper


    protected override DependencyObject CreateShell()

    {

        return this.Container.GetExportedValue<Shell>();

    }


    #endregion

}

Now lets enable MEFedMVVM

In order to do this we will simple need to implement the IComposer interface from MEFedMVVM and then return the AggregateCatalog property (that is given to us by PRISM)

#region Implementation of IComposer (For MEFedMVVM)


public ComposablePartCatalog InitializeContainer()

{

    //return the same catalog as the PRISM one

    return this.AggregateCatalog;

}


public IEnumerable<ExportProvider> GetCustomExportProviders()

{

    //In case you want some custom export providers

    return null;

}


#endregion

In this case we will return null as the GetCustomExportProviders. This is a feature used if you have some custom ExportProvider you want MEFedMVVM to use.

The last step (which is the actual line of code to enable MEFedMVVM) is where we tell the MEFedMVVM LocatorBootstrapper to use this class as runtime composer.

protected override DependencyObject CreateShell()

{

    //init MEFedMVVM composed

    MEFedMVVM.ViewModelLocator.LocatorBootstrapper.ApplyComposer(this);


    return this.Container.GetExportedValue<Shell>();

}

As you can see I have put that line of code in the CreateShell method so that the Composer is applied as early as possible so that all views can use MEFedMVVM.

 

Now you can start using MEFedMVVM as you would in a normal project… For example in the Shell you can say

<Window x:Class="MEFedMVVMAndPRISM.Shell"

        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

        Title="Shell" Height="300" Width="300"

        xmlns:mefed="http:\\www.codeplex.com\MEFedMVVM"

        mefed:ViewModelLocator.NonSharedViewModel="ShellViewModel">

and the ShellViewModel would be

[ExportViewModel("ShellViewModel")]

public class ShellViewModel

{

    public string Text { get; set; }


    public ShellViewModel()

    {

        Text = "Hello from the ViewModel";

    }

}

Of course here I am not really leveraging MEFedMVVM capabilities, yet the purpose of this post is not to show those capabilities but to show how you can use PRISM and MEFedMVVM together and take what is best from both. To read more on MEFedMVVM visit the codeplex site.

I create a small sample project to showcase both PRISM and MEFedMVVM working together.

Download sample

Capture

Making a generic UpdateSourceTrigger for PropertyChanged in Silverlight

In my previous post I explained how Silverlight 4 lacks the UpdateSourceTrigger for PropertyChanged. I focused on how you can overcome this issue for one of the biggest use cases, which is the TextBox.

In this post I will show how one can do this for any Dependency Property of any Framework element. Please note that this post is quite an experimental one. Probably the use case you are looking for is for the textbox scenario, if that is the case I would suggest that you use the more explicit approach i.e the one I show in my previous post. The take away from this post should be more the idea of how things work rather than the actual code I am using here, this code was never tested in production thus it might contain memory leaks and other issues.

The key for updating the binding when a property changes is to actually know when the property has changed and then force the binding to update the source. In WPF there are multiple ways of doing this, one of which is to use the DependencyPropertyDescriptor class. This class allows you to hook an event handler for when the specified property has changed. Unfortunately in Silverlight there is no DependencyPropertyDescriptor class thus one has to resort to some ninja trick Smile After doing some internet crawling I found an interesting approach using attached property creating and hooking to the property changed. The idea is that you create an attached property and you bind the newly created attached property to the property that is consuming the binding.

Let’s dig a bit deeper

Let’s say you have the following binding

<TextBox Text=”{Binding SomeText, Mode=TwoWay}”

The Text dependency property is consuming a binding and you want to update the source of the binding as soon as the property changes.

You create an attached property and you bind it to the Text property of that TextBox. This will get you notified when the text changes because when creating the attached property you can have a property changed handler. In the property changed handler you update the source of the binding.

You would create the attached property and the binding for notifications like so

// Create attached property

var listeningProperty = System.Windows.DependencyProperty.RegisterAttached(

    "ListenAttached" + propertyName,

    typeof(object),

    typeof(UpdateSourceTriggerProxy),

    new System.Windows.PropertyMetadata(OnPropertyChanged));


//Create a binding that will be updated when the property changes

var listeningBinding = new Binding(propertyName) { Source = element };

element.SetBinding(listeningProperty,

    listeningBinding);

Ok so I showed how you can workaround the lack of DependencyPropertyDescriptor in Silverlight for property changed notification, now how do we update the binding?

In order to do this we will need to get the instance of the Text Dependency Property. Unfortunately we will need to resort to reflection in order to get the instance of the Dependency property. We can do this by name

var propertyFieldInfo = frameworkElement.GetType().GetField(newPropertyName + "Property");

if (propertyFieldInfo == null)

    throw new InvalidOperationException(String.Format(

        "The property {0} does not exist in the element {1}. Make sure you specified the correct property.",

        newPropertyName, frameworkElement.GetType().FullName));

//Get the dependency property the binding is applied to

var property = (DependencyProperty)

    propertyFieldInfo.GetValue(frameworkElement);

As you can see I am attaching a string “Property” to the actual property name (in this case Text) when I try to get the dependency property by reflection. Even though in XAML you specify “Text” as the property name, the actual dependency property name is TextProperty (which is a coding standard for dependency properties), “Text” is how the property is registered to the framework.

So why did we need to get the actual instance of the Dependency property? We had to do this in order to get the Binding Expression so that we can force the binding expression to update the source of the binding with the new property value. This would look like this

_bindingExpression = element.GetBindingExpression(BoundProperty);

And to update the source (i.e in the property changed handler of the attached property) we would do this

_bindingExpression.UpdateSource();

How is this approach generic?

Well let’s see what we did in the “Dig Deeper” section.

– We are getting a dependency property by name

– We get the Binding Expression from that dependency property

– We create an attached property which will be our way of hooking to property changes of a specific dependency property.

mmm… So as such we can have 1 attached property of type string that will generate this hook and update the source for us. If we do this we would have something like this in our XAML

<TextBox Text=”{Binding SomeText, Mode=TwoWay}” local:UpdateSourceTrigger.PropertyName=”Text” />

Not great but not too bad, it will do the trick for now… So here is the code for the attached property (you have to download the sample project)… Its exactly what I explained in the section above.

Please note that I am creating the hook inside a separate class UpdateSourceTriggerProxy. I am doing that so that the operation is atomic and everytime you use this approach we have a different instance of UpdateSourceTriggerProxy doing the hook for updates and the actual update. The object instance we be kept alive because of the property changed delegate.

Download sample project here.

Closures in C# can be evil

I had a problem with yield and closures. A friend Glenn Block gave me a good link on this. you can read it here >> http://codebetter.com/blogs/matthew.podwysocki/archive/2008/09/12/side-effects-and-functional-programming.aspx

here is an abstract from the blog about the problem. This can cause a lot of pain and that is why I am sharing it so that you do not fall in the same trap!

Closures and Lazy Evaluation

One last topic for this post revolves around variable instantiation around closures and what it means to you in regards to lazy evaluation.  Let’s look at a quick example of some of the issues you might face. 

C#

var contents = new List<Func<int>>();
var s = new StringBuilder();
for (var i = 4; i < 7; i++)
    contents.Add(() => i);
for (var k = 0; k < contents.Count; k++)
    s.Append(contents[k]());
Console.WriteLine(s);

What we might expect the results to be in this case would be 456.  But that’s not the case at all here.  In fact, the answer you will get is 777.  Why is that?  Well, it has to do with the way that the C# compiler creates a helper class to enable this closure.  If you’re like me and have Resharper, you’ll notice that it gives a warning about this with "Access to modified closure".  If we change this to give ourselves a local variable inside the loop closure construct to initialize the value properly.  If we do that and change our code, it will now look like this:

C#

var contents = new List<Func<int>>();
var s = new StringBuilder();
for (var i = 4; i < 7; i++)
{
var j = i;
    contents.Add(() => j);
}
for (var k = 0; k < contents.Count; k++)
    s.Append(contents[k]());
Console.WriteLine(s);

Jason Olson has a pretty good explanation in his post "Lambdas – Know Your Closures".

 

Hope it helps!