::ErrorOK

The title should probably be enough, but in case it isn’t I am talking about multiple grids in a single view that need to share row size or column size. A good example of this would be if you wanted to split grid rows up into groups, then apply each group to an expander, thus allowing you to show and collapse the different groups of rows. However, when everything is expanded, you still want all your columns to line up. Well, you can use the Grid.IsSharedSizeScope attached property for this. There are some msdn docs on this here, but i found them to be somewhat lacking in detail. So here is is my idiot proof guide (really just the information left out of the msdn article) on how to share grid layout size info.

The most important thing to note is that you only use the attached property to enable (or disable) a scoped region to share size info within. This is extremely important to understand because scope is not inherited by children if you override it. For example, if you were to create a grid within a grid and put the attached property on both grid nodes, the second grid would override the scope of the first, and you would NOT get your shared sizing. You only ever want to put the attached property ONCE for the ENTIRE scope of shared sizing.

With that out of the way, all you need to do now is give your row or column definitions a unique identifier on the SharedSizeGroup property and then all rows or columns that share the same unique identifier will also share the same hight or width respectively. You should also note that this only works for explicit or Auto sized rows and columns. If you specify a star on a shared item, it will default it to Auto.

No Comments Yet...

This is an issue that I just ran into and was a little confused as to why it was happening, but upon thinking about it for a moment it makes perfect sense.

When you are creating your DP’s, you have the option of specifying a default (initial) value. The problem with this value is that it is created and stored statically. So if you are creating a DP for, say, a collection, and you initialize it statically in the DP definition then your collection reference now exists statically. So regardless of whether or not you create ten instances of your DO, they will all contain the same initial value because they will all point to the same static reference.

So the conclusion to this quick lesson is that you should never initialize your DP’s with reference types, always perform this step at instantiation to guarantee unique DP values per object instance (unless of course you want to share the reference). As for value types it doesn’t matter nearly as much because the value is copied anyways.

No Comments Yet...

Ever wanted to return an anonymous type from a method or property, but then find out you can’t use it because there is no valid return type?  Well I have, and I will explain how to get around this issue.

The solution as you may have guessed is to use dynamic types, which allow you to build the type definition at run time and return it.  Since there is no static compilation type checking, it doesn’t care that you can’t define the return type of your method or property.  This isn’t something very common, or even recommended in most situations, but it can come in handy in a pinch.  Here is some totally useless, but good sample code explanation.

private bool flagValue = false;
private bool isFlagValueSet = false;

private dynamic Flag
{
    get
    {
        return new { Value = flagValue, IsValueSet = isFlagValueSet };
    }
}

public bool Test()
{
    return Flag.IsValueSet ? Flag.Value : false;
}

All you gotta do is ensure that you reference the Microsoft.CSharp.dll to get access to dynamic types.  You won’t get any intellisense on the flag variable, but that’s because the type information is computed at runtime only.

No Comments Yet...