Almost all of the Windows Phone apps have got a small offset on left and right side. I believe that, it’s got something to do with better user experience. As a layman in this matter, I can  just guess that it makes human eye more comfortable to look at content which doesn’t touch edges. Whatever it is, that’s how apps are being developed and we have to accept that. Although, this is not the topic of this blog post, I’m intentionally mentioning about it, because it has influence on how the scrollbars are placed and how do they look like in the app. Yes, scrollbars.


When the content of the page, designed with those both sides offsets, has got a list, grid or a scrollable content in it, the scrollbar itself is placed on the edge of this content, which means, that it resides not exactly on the edge of the screen, as shown on the above screenshot.

Code for the page, that I took above screenshot, is pretty straightforward

As you can see there’s a main container (Grid) with Margin attribute as a defined resource BasePageOffset

In this case, our interests should be focused on the first and third value of this defined resource, which indicates left and right margin, so called offset. Those two make all the content, being placed inside the Grid, to move a bit into the center of the screen. Which makes our ListView and its scrollbar being moved 10 points from the left and right edge of the screen towards the center. Effect of it is visible on the first screenshot. Solution to this issue, is really simple and comes with manipulation of margins.

Notice the negative left margin in the ListView. All right, but after this change the items of ListView are still touching the edge of the screen and whole idea was not to let them to…No problem, you just have to move your ListView ItemsPanelTemplate template the same amount of space (margin) to the opposite direction by, again, setting a margin, like so

After those changes your scrollbar should be on the right place


My example was showed on the ListView control, but this ‘trick’ could be applied to GridView and ScrollerViewer as well

Actually I lied in the title, I haven’t learned it today but there was a day when I’ve stumble upon this attribute in someone’s code and started using it ever since. This is one of these things that makes your life much easier while debugging. What does this DebuggerDisplay attribute do exactly ?

Let’s start from the beginning. By default when inspecting an object e.g. House:

we will se something like this:


You can say, but that’s not so bad, because we can inspect this object in details really easily by just expanding information about it, indeed:


As you know this process, which sometimes cannot be omitted, could drive you mad, especially when you are almost at the end of expanding really complex object and then you miss clicked the last expanding arrow, so everything collapsed, and you’ve to start ‘digging’ from the beginning. Even though it could be a painful process it’s pretty straight forward to inspect whatever information you’re looking for. Things could get bit more annoying when you’re dealing with collections.


This collection is just an example, of really small one, that still could be handled by this ‘clicking and expanding’ process, but imagine a collection with tens or hundreds of elements (probably you don’t have to imagine anything ‘cause you’re deal with those on regular basis) in which you want to check some deeply hidden property of a child of a child of a child of a child of your object. That would be a nightmare. With help comes DebuggerDisplay attribute which is used as simple as writing something like this

which gives us an effect of showing whatever information you need (even the one deeply hidden inside an child of a child etc.)


Now you’re ready to use it and make your debugging life much easier. BEFORE that, though, you have to be aware of some possibilities and good practices in this subject. You can write basically any code you want in the attribute {string}. This expression is going to be evaluated and than presented while debugging. Previous chunk of code (with DebuggerDisplay attribute) is BADLY written and I’ve put it only for exampling purposes. The first BAD thing about it is that it’s going to evaluate three expressions, and evaluation costs. Second BAD thing is putting a collection indexer reference in it, which can cause exception. So how it should look like ? Like this:

The best practice for DebuggerDisplay attribute is to use as less expression to evaluate as possible and this can be achieved using one property which is going to present your object as you wish. For more specific information(and what this ‘nq‘ thing is doing in the DebuggerDisplay attribute {string}) go to this msdn blog post, which explains in details good and bad practices. It’s not so long and it’s definitely worth reading

Not so long ago I had a small problem with inspecting pretty complex exception. Usually what you see after some exception is thrown is basically this kind of window:


I’ve highlighted Break when this exception type is thrown because without this box being ticked you won’t be able to see $exception pseudovariable inside your Watch window, but about that in a second. After seeing that, usually you click on View Details to check what exactly had happened:


Inspecting all of the provided information doesn’t give you much more information about Exception itself besides the type of it and that there are some more specific information inside the Exception (two exception parameters). Even though we don’t have much information about ‘insides’ of the exception we can tell something from exception name itself, right ? That’s correct, you can figure out what kind of exception or with which group of exceptions you’re dealing with, but you still don’t have specifics. With help comes mentioned earlier $exception pseudovariable.


As you can see there’s a lot information about exception that was thrown. For us the most important part is kept inside ConsoleApplication1.ComplexException:


Now you know exactly what had happened. You can do a little tweak around displaying it in the Watch window, so you won’t be bothered by other properties of Exception object. Just cast $exception to specific Exception type, like so


and voilla