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.


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)


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">
                <Button Width="200" Height="150" Background="{Binding Item2}">
                    <TextBlock Text="{Binding Item1}" Foreground="White" FontSize="25" FontWeight="Bold" VerticalAlignment="Center" HorizontalAlignment="Center"/>

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

Join us at Thynk Software

DISCLAIMER: This is classified as an old boring recruitment post but hey it’s one I need to call out… I just founded a new company, Thynk Software and I need smart guys that can help me grow and execute projects.

Thynk Software is currently looking for software developers to help out in the product delivery space. Currently we have a pipeline of Windows 8 apps and also Web application (based on Azure). Most of the work can be done remotely (with some travel to the home office which would be covered by Thynk). If like us you are passionate about developing on these technologies please contact us (

Would love to hear from you. I am sure that together we can figure out a way to work together !

Thynk Logo

WPF Radio Buttons… “Once it is checked it just won’t uncheck”

Today I was doing some Sunday morning coding (why read newspaper when you can code right? ) and stumbled upon an issue with Radio buttons in WPF… Basically if you have a set of Radio buttons with the same group name, once you check one of the radio buttons you cannot uncheck it.. This was causing me grief since I wanted to enable the user to be able to uncheck it back…

This might seem quite simple to solve but I wanted to write this post to show how WPF Dependency property system is superior from any other XAML platform …

So first off, I don’t want to create a sub class for the radio button to have this behavior and I would also like that i can re-use this behavior for other Radio buttons… The first thing that pops to mind is, “let’s create an attached property”. However with an attached property on it’s own we cannot do much… the idea of using an attached property works well if you can hook to an event and react accordingly adding the behavior that you want. However in this case what is happening is that the radio button is automatically suppressing the checked and unchecked events if a Radio button in a group is checked …

FrameworkMetaData to the rescue …

One thing that is not heard of much however it is there and a very important part of the WPF DependencyProperty System is CoerceValueCallback. With CoerceValueCallback you can validate the value of a property before it is set.. Example let’s say the Minimum and Maximum properties of a slider control, the Minimum property can have a CoerceValueCallback that validates that the Minimum value is never set more than the maximum..

In this case we can use the CoerceValueCallback to auto set IsChecked to false if the previous value of the Checkbox is set to true. The only issue now is that FrameworkMetaData get’s attached per Control Type, thus if I use the FrameworkMetaData it will be applied to all radio buttons in my solution… well for that we can use Attached properties… we can have an attached property and when set on a radio button we will enable this behavior if not then we don’t do anything …



and here is the attached property



And that’s it…

Silverlight, WinRT, WinPhone, they are really good XAML platforms, however for me WPF is just great for devs.. it gives the dev the power and flexibility needed to build clean and large scale solutions… Aaa well, maybe it’s passion from my first love Avalon speaking now… the good old day !

If you want the actual code so that you don’t need to re-code it, you can find it here 





MVVM in the web world


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


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


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();


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.


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


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


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 !

Thinking in boxes

So if you have been following my blog lately you would have noticed I am doing some adventures in HTML lately… No I am not leaving my XAML love behind I just feel that I should look at other stuff and get ideas from different technology stacks.


In todays article I want to show how layout specifically one nicknamed as the “Traditional Box Model” comes in handy to know for those that like me come form a XAML background, a background which has a rich layout system, a background where panels are the kings of the realm. We’ll see how in HTML, yes this is a bit harder, but very achievable. We will also see how HTML5 and CSS3 introduces some really cool concepts and how layout becomes comparable to XAML layout and panels.

I remember back in the days when I used to do web (around 6 years ago) many would layout the page by using a <table />. Yes a table believe it or not! You might ask yourself “but a table is really for displaying lists of data no??”. Well layout is not really the most intuitive thing to figure out in HTML and devs love shortcuts thus yes; tables were (and in some cases still are) a tool to do layout. But is it the best way to do layout?? No, its not really… A more flexible way to do layout is by using divs. Enter the “Box Model”.

Box Model

Lets say we wanted to do something like this





One way of picturing this layout is that every box is a div (some might argue it doesn’t really need to be a div but really any element that has display: block, but for simplicity, let’s say divs for now). A div by default will occupy all the width available, so if we had the following HTML the output would not really resemble the layout we have in the image here.



This would actually render into something like this


Blue div == ‘mainSection’; Red div == ‘sideSection’;

In order to get these 2 divs side by side, we need to specify a CSS property called float. You can specify left, right, none or inherit. In our case we will want to set the mainSection to float: left and the sideSection to float: left. The piece that many forget to add, which then results in chaos is to set to the next element (in our case the footer) the css property clear: both. This will restore the flow of the document and basically in our case it will prevent the footer from going up on the side of the sideSection div.

So here is the CSS styling we have done so far


And here is the result we got



Nothing really changed did it?? Nope it did not. And the reason for that is that as I was saying before a div will occupy the full width available by default. What we can do here to make the mainSection and sideSection layout side by side is to set a width for the divs. And we finally get a result that looks like this



What is annoying here is that we had to specify a width to both divs… In all fairness the sideSection can stay without a width and this would make it occupy the reminder width inside the page. That’s cool BUT we want our mainSection to take the dynamic width and not really the sideSection, right? Yes you can do it with the Traditional Box Model BUT instead lets have a look at how we can do this and much more using the new hot stuff from HTML5 and CSS3.

Enter “Flexible Box Model”

The flexible box model is still something that browsers are experimenting with in fact you’ll find that you will need to annotate the properties for this with –webkit and –moz- and –ms . don’t you love experimental things Smile Anyways, the idea with this is to be able to be more dynamic, to have a proper way how to specify layout. With this model you’ll be able to specify if you want the flow to be horizontal or vertical (just like orientation in StackPanel for those XAML guys reading) you’ll be able to specify how much “percentage” of the space available vertically/horizontal should a box take up (just like ColumnDefenitions and RowDefinitions in Grid for those XAML guys reading). You will also be able to specify the alignment and yes also the index you want each box to be in…

Does this feel more like panels in the XAML world. WUHUU now we are talking …. so let’s pimp up our screen with some hot and spicy HTML 5 / CSS3.

Let’s start fresh… here is some new HTML … Basically a parent div with 4 divs and lets start rocking!

imageThe first thing we want to do is tell the container div that we want to use the new box model. To do so we set display: box. Since this is experimental still we need to specify display:-webkit-box;

As I was saying the new flexible box model supports orientation, you do this by specifying box-orient. As expected this takes horizontal and vertical . P.S do not forget to add the –webkit- and all the rest.



And this gives us


This might look like its nothing but hey we just started… Ok seems like these boxes are only using the width that the inside text measures, lets make them use all space available evenly (just like we would do with a XAML Grid)

To do so we use another cool CSS3 feature. The magic property is called box-flex.


And this gives us


Already very exciting isn’t it?! What was that 1 we set to box-flex. The 1 is basically being used in the following formula >> widthOfParent * 1/numberOfElements = widthForElement (ex: 600 * 1/4 = 150). For example if I set 3 for one of the boxes, I get this result which is Box3 is as big as the other 3 boxes all together. (doesn’t it sound like a * measure for ColumnDefinitions in XAML Smile )


Yes resizing the browser window will nicely resize these boxes just like one would expect. AWESOMENESS on a stick!!!!!

What if I want that all boxes are 100px BUT (since I am a crazy evil designer that likes to bully developers) I want them to be all centred in the middle of the screen. Well to give each box a size we know what we have to do, set the width css property. To specify how to layout them there is a new CSS3 property called box-pack. This property will tell the Browser how to distribute the free space. You can set this to start, end, center and justify. Lets go for center (-webkit-box-pack:center;) and we get something like this


if I specify –webkit-box-pack: justify I get this


What if we want to change the rendering order of the boxes? CSS3 to the rescue Smile box-direction a new CSS property will do the trick by setting it to reverse. –webkit-box-direction:reverse





And yes you can even change the order of the boxes (just like a XAML Panel) by specifying the box-ordinal-group





Last but not least is box-align which can be center, left, right and also stretch.




Check out more details on this over here. I hope that this article really shows you that HTML5 and CSS3 are really making some very cool and exciting things for us devs. If like me you come from a background where layout is something really rich (which in any XAML technology, layout is super easy to work with) HTML5 and CSS3 are building mechanisms to be leveraged and easily build awesome web applications.

I am very excited about this, layout sometimes is taken for granted but what is a good UI platform without a good and flexible layout system. Thankfully HTML5 and CSS3 are here to rescue us from the evil designer requests Smile

HTML5 CSS3 Javascript vs XAML .net and Silverlight

Introduction >> The clash of the Titans is on

Developers right this second are at some bar / restaurant / lounge / god knows where else being “social” i.e. having geeky discussions about technology, what language/platform is best to use or even better “what’s coolest right now” Smile

I am one of those developers and I must say, when it comes to such discussions I am always biased towards XAML technologies. Yet recently I started diving in what I used to call the “darker side” i.e. HTML5, JS and CSS3 (the “dark side” is reserved for things like Java Smile ). It’s been years (6 to be exact) since I was doing some HTML and Co and I must say; I am really impressed. HTML5 just takes everything to a whole new level BUT what impresses me most is JS and CSS3.

JS because the browsers are natively exposing APIs such as GeoLocation, Canvas drawing, local storage and also indexed DB (and more APIs). BESIDES THAT, what sells JS for me, is the new libraries developers are building such as JQuery and Knockout.js. Working with javascript today is just loads and loads of fun !!

CSS3 because WOW its frekin cool!! The new box modelling with the Flexible box model, the gardients, the transforms, the transitions and I can go on and on…

So yea I must admit, web development (presentation layer) of today is becoming loads of fun! Backend for Web with MVC its also frekin cool! so I guess the questions that readers of my blog / people who know me would ask “Is Marlon turning his back on XAML?” The answer is simple and its NO, my car number plate still says WPF so I guess I cannot change everything now Smile Joking aside, I see both technologies as super awesome and both of them have a different realms (to a certain extend). “to a certain extend” for the reason that WinRT will also support HTML5 JS and CSS3 as a first class citizen just like it will for XAML and C# / C++.

Does this mean we should say bye bye to XAML and just focus on HTML5 and Co?? If it can do web + desktop why bother looking at XAML??

Ok so lets be a bit metaphoric about this and let’s compare technologies with cars. There are many different brands, there is Audi, there is Honda and you can go on and on… They all take you from place A – B. How they take you is a bit different, some are super confortable, some are fast. Some are perfect for one thing some are perfect for another! You buy a car that fits your needs and the same can be said to technology you decide to use. There are those scenarios, for example when you are moving house, where you do not have the luxury to use your “preferred car” because hey; if its a sports car, it will be no good when you are moving, so in such a case you are coerced to use a specific type. Such an example for developers is the web / mobile phones … Yet again just like in real life there are many different trucks for moving Smile there is HTML5, and then there are the plugins (Flash, Silverlight) …

Which one should you go for? HTML5 or Plugins?

Looking at web tech today I would say go for HTML5. It will work on devices such as phones, if done properly it will be super fast. On the other hand I would strongly suggest you consider SL / Flash if your users cannot install/already have a browser that supports HTML5. In that case then yea I would not go for the HTML < 5 because you’re in for nightmares! Maybe mix and match! Some things are better done with plugins some other with HTML. Do not be afraid to try both worlds, it will not hurt.

What about WPF??

WPF will still have a place but I guess we will slowly see it being used lesser and lesser, reason being with WinRT you are not using WPF you are using WinRT, yes its XAML but NO it is not WPF. There are cases such as VS and similar heavy weight products that would require something like WPF. Trading applications and internal banking applications is another example for WPF apps. But yea if you are building a simple app, going forward one would be better off with something Metro style i.e. WinRT based. So should WPF developers say “cr*p I wasted a lot of time learning something I will not use anymore”?? Whoever says that is really talking bull***t! WPF thought us a lot, WPF gave us so many concepts and ideas… WPF will always continue living in other technologies… Its concepts that really are hard to learn not how to use a framework, example DataTemplates, ControlTemplates, Binding and many other concepts … For me WPF showed me what an awesome API should look like! Besides that you learnt XAML that is something that is not a waste of time since XAML is here to stay !

Final verdict – Who will be the last technology standing?

None probably Smile technology evolves … sorry my fellow geeks, I like you used to treat a technology stack (and must admit still do sometimes) as my one and true love and I could not use another technology without feeling that I am being MARLONCHANGE… well its not the case, when it comes to technology you can mix and match as much as you want and no you will not be called a “Cheater” Smile

Take it from me, if you did not have a look at HTML5 and co, maybe its time for you to do so. Maybe you will not use it but I am sure you’ll get something out of it. I am learning so much, getting so many new ideas (that yea I can even apply for WPF) from doing some HTML5 and Co.

Hope I did not bore you to death with this post but I felt I needed to share this with you guys! I’ll be posting more on HTML5 and Co this year but yea of course I will also do the same for XAML and Co.

Long live XAML

Long live HTML5 (and co)

>> No source code to download just thoughts …

Timeouts for long running operations…

Today I stumbled upon a timeout issue while building a web application and felt like I need to share this for those that like me wasted/are wasting hours trying to figure out why you are getting a timeout.

Here is a diagram that show the structure of the request response stack I have.


The reason why I went for an AsyncController is that the long running operation is not CPU-bound processing thus the thread that would be waiting for the response would be wasting its time waiting. More info on why and how to use Async Controllers in MVC3 can be found here.

All is fine and good until my I hit a request that took more than 1 minute, and then the nightmare of timeouts begun… So first thing I did is make sure I make the timeout for the WCF service longer. You can do this by setting the sendTimeout and the receiveTimeout of the binding in the binding configuration.


Don’t forget to do the same thing on the client side otherwise you’ll get in trouble (the config is the same as the server, and if you are using VS to generate the config then this will be done for you when you refresh the ServiceReference).

At this stage I said, wuhooo, it’s all done… but nope… it was still timing out … I was confused and puzzled… WHY WHY WHY!!!!!

Well AsyncController also have a timeout (or 90seconds as per MSDN doc), you also need to set the timeout to the async controller action in order for this to work. You do this by setting the AsyncTimeout attribute on the action that you want to extend its timeout.


With this in place all started working… but yea the errors don’t really help !

Hope this helps…