Rob Relyea


May 2004 - Posts

  • When are IDs necessary in XAML & what about ID="Root"?

    Filed under: ,
    I've seen this in several XAML examples on the root XML element and I've
    seen plenty of examples without this attribute.  When is it needed and is
    the value "root" special?

    About IDs

    First let's talk about IDs.  TheRHogue replied.  I've taken his reply as the basis for the answer below with some editing...

    You use the ID property for accessing an element from you code. Generally, if you don't need to access the property in code behind you don't need to set an ID.

    Technically, when the element is instantiated, the variable is given a unique name or the name you declare with ID.

    For Example:

    .xaml (page):
    <TextBox ID="tb1"...>

    .xaml.cs (codebehind):
    tb1.Text=“Hello World“; // set the textbox's text property to Hello World

    If the ID property was not set, you could not access the textbox element directly.

    What about the Root element?

    Several XAML pages out there have set ID=”root” on the root element of the page.  While this is fine to do if you want, you don't need to do it.  Here is why:

    All code that you embed in the page or in codebehind is compiled into a new class.  This class automatically derives from the original root element you had in your page.

    So in this example:


    We build a new class that derives from Window and add all the page logic and some generated code into that class.  When you load Page1.xaml during runtime you end up with a tree like this:


    If you'd like to name that class, you can do that:

    <Window def:Class=“MyWindow“>

    You'll then end up with:

    </ MyWindow>

    So, in code, to refer to the root element in C# just say “this”.

    this.Height = 200; //for example...

    For some more details, see my January 2004 post: MarkupCompilation: XAML, BAML, .g.cs Details

  • Comparing Visual Appearance and Developer Experience in a markup-bake off

    Filed under: ,

    Adam Kinney has posted his xaml app that he entered into a markup-bakeoff that Gerald Bauer organized.  Nice job Adam.

    Follow Adam's link to all the entries - they are very interesting to read through.

    Visual Appearance

    I found it interesting that the different entries all had different looks based on the UI plaform they were built on top of.  This contest, I believe, has focused on the markup, not the appearance in the end.  In the end, a key differentiation will the be user experience.  In the end, Longhorn applications are going to be able to look significantly more polished than most other platforms.  The theme for our Buttons will evolve to take advantage of our vector rendering over time.

    I was disappointed by the default look in Flex - I thought the buttons would have used more Flash power.
    SwiXml targetting mac has the most polished controls right now.

    Adam's entry shows off a few things that the others didn't have or didn't use:

    • Flowing Layout - as you resize the window, the ui can reflow a bit.
    • Non-gray look - gradients are a nice addition

    With the just released WinHec build, Adam could consider using the new <Grid> to get different resizing characteristics than the FlowPanel.  (SimpleText gets replaced by Text in the winhec build also...)

    Developer Experience

    I like the fact that Adam used a style to set properties on all the Buttons

    He should consider declaring the Gradient as a resource and use a resource reference on the FlowPanel's Background property.  This will keep the UI defintion cleaner.  It also shows off resource references.  I guess you want to keep it simple, but also want to show off some of the power...

    Gerald - It would be interesting for the sample site to show the code behind for all the examples.  We are only seeing part of the picture for many of these samples.