in

Dé specialist in .NET trainingen en consultancy

Jo-wen Mei

januari 2009 - Posts

  • Some WPF databinding tips

    Databinding in WPF is very flexible and can therefore be less obvious at times.

     

    * You can use the "/" to specify the current item in a collection.

    I'm not going into any details, you should definitely read Ian Griffiths' article on this!

     

    * I'm using the following xaml to fill the dataContext in my controlTemplate:

    DataContext="{Binding RelativeSource={RelativeSource TemplatedParent}}"

    The application works fine, but Cider (Visual Studio Designer) complains that I must set the Path property.

    I'm interested in the entire object, and not a specific property though.

    You can fix this by using the Path=. notation, which resolves to the same object.

     

    Did you know readme files can contain useful information? :p       [check out section 2.3.8.7]

     

    * Binding path "TextBox.Text" vs "Text"?

    If you bind to a path called Text, WPF uses reflection to resolve the name. If you use the class-qualified name, binding avoids the reflection performance hit. Class-qualified names also allows binding to attached properties!

     

    * Not all DP's have the same default binding mode

    You'll get in trouble if the binding mode is two-way, but the CLR property that it is bound to is read-only... You can't assume what the binding mode is!

    It is always a good idea to explicitly specify your binding mode. Also remember that OneWay is slightly lighter than TwoWay!

     

    * RelativeSourceMode.PreviousData

    If you bind to a collection of objects and need to show the change from the previous item the current item then this little trick can be very useful...

    Pass the current item and the following binding into a IMultiValueConverter

    {Binding RelativeSource={RelativeSource PreviousData}}

    The multi value converter now just need to work out what the difference is!

    Posted jan 23 2009, 11:11 by Jo-wen with no comments
    Filed under:
  • WPF & Inheritance

    Probably one of the first things you've tried is to subclass Window (or Page/UserControl/etc) and expected to get the xaml for free in derived classes...

    This is called "visual inheritance", and it doesn't work as expected (yet)....  This is a major issue for WPF.

     

    Code inheritance is not a problem, and works as we're used to. As everything we do in Xaml, can be done in code there's no loss from a functional perspective...  it's just too much work

     

    So you can create an (abstract) base class that derives from Window (code only!), and derive new windows (including xaml!) from your custom base class...

    It's possible to make your base class abstract, unfortunately you loose CIDER (Visual Studio Designer) support. Blend can still create classes that are derived from an abstract class though.

    Here's an example

     

    Note: if you download the Blend SP1 you get another 60 days for your trial version :)

  • VSPerfMon.exe vs unit-tests

    I was stepping through one of my unit tests, and all of a sudden Visual Studio pops up an error:

    "The Visual Studio performance and coverage logging engine is already running on the computer. Therefore, the test run cannot continue. Close the pending performance or code coverage session and then rerun the tests"

    Hmm, I was not running an actual performance session at the time, but I was experimenting with that a few days ago.

    So I stopped all sessions and closed all performance related tool-windows. Visual Studio still couldn't run the tests. Not even after restarting it...

    Luckily, the error message is quite clear, so I found that  you should kill VSPerfMon.exe.

    And we're back in business....

  • Silverlight decompilation

    When you build a Silverlight application, you compile your source files (inc. XAML and embedded resources) into assemblies (dlls).

    Those assemblies (plus any 3rd party ones plus MS assemblies that are not part of Silverlight) are then collected together along with a manifest into a packaged

    archive – or in other words, a ZIP file. Except, the extension is changed to be a .XAP (pronounced "ZAP").

    The advantages of this archive is that it's compressed, and simplifies deployment.

    Here are the steps to decompile a silverlight 2 app:

    1. Surf to the entry page

    2. View the source for the webpage and look for a reference to a xap file.

    3. Type a request for the xap file into your browsers address bar.

    (keep the same domain, but replace the page name with the partial path that points to the xap file including "clientbin")

    4. Choose save as to save the xap file locally

    5. Rename the xap file to add the .zip extension.

     

    This comes in handy if you want to learn how others made their stuff... and that if you want to prevent others from doing this to your code, you should take preliminary actions!