in

DĂ© specialist in .NET trainingen en consultancy

Jo-wen Mei

januari 2008 - Posts

  • Geen BreakPoint, maar een TracePoint

    In navolging op mijn vorige blogpost over DebuggerDisplay attributes, nu eentje over het gebruik van TracePoints.

    Als je een breakpoint gebruikt stop je de execution flow, en dat is niet altijd gewenst. Vaak wordt als alternatief hiervoor Trace.Write() statements aan de code toegevoegd, zodat informatie in het output window gelogt kan worden.

    Om de code minder te vervuilen kun je TracePoints gebruiken.

    Er zijn 2 manieren om deze toe te voegen:

    1. Rechts-klik op de betreffende regel en kies Breakpoints | Insert TracePoint
    2. Rechts-klik op een bestaande breakpoint en kies When Hit

     

    image

     

    In dit window kun je eenvoudig een bericht specificeren dat naar het output window gestuurd wordt (incl variabelen of zelfs functions).

    Hier staat standaard de optie "Continue execution" aan wat er dus voor zorgt dat de flow niet onderbroken wordt.

     

    Verder heeft de TracePoint vergelijkbare functionaliteit als de BreakPoint, zoals op condities checken en filtering toepassen.

  • Debugger Display Attributes

    Ok, er is een super coole debugging feature waar ik laatst achter kwam (overigens al vanaf VS 2005).

    Regelmatig ben je tijdens het debuggen geinteresseerd in bepaalde properties van een class. Iedereen kent wel het properties window waar je doorheen kan scrollen als je met de muis boven het object hangt.

    Maar het is ook mogelijk om waardes van bepaalde properties direct te tonen! Dit kan met de DebuggerDisplay attributes.

     

    Ik heb deze code:

    using System;
    using System.Collections.Generic;
    using System.Text;
    using System.Diagnostics;

    namespace EventHandling
    {
        [DebuggerDisplay("Het ID is: {_ID}, en de naam: {_Name}")]
        public class CustomClass
        {
            public CustomClass()
            {
                _ID = 1;
                _Name = "Jowen";
            }

            private int _ID;
            public int ID
            {
                get { return _ID;  }
                set { _ID = value; }
            }

            private string _Name;
            public string Name
            {
                get { return _Name;  }
                set { _Name = value; }
            }
        }
    }

     

    Nu zie je in de debugger het volgende:

    image

    In plaats van het standaard scherm:

    image

     

    Natuurlijk is het in dit voorbeeld niet zo'n wezenlijk verschil, maar als je een diepe structuur/hierarchie hebt, kan het je veel tijd schelen!

  • Event handlers in xaml

    Je moet je goed bewust zijn van wat er kan gebeuren als je event handlers koppelt in xaml.

    De volgorde van het parsen van de controls gebeurt adhv de volgorde van definitie in het xaml document.

    Het is dus goed mogelijk dat je in de code van een eventHandler verwijst naar een control die op dat moment nog helemaal niet bestaat.

     

    Als voorbeeld pakken we de comboBox.

     

    De xaml:

    <StackPanel>

        <ComboBox IsSynchronizedWithCurrentItem="True" Margin="56,57,73,0" VerticalAlignment="Top" Height="29"

    SelectionChanged="comboBox1_SelectionChanged" SelectedIndex="0">

            <ComboBoxItem Content="1"/>

            <ComboBoxItem Content="2"/>

        </ComboBox>

        <Label Content="blub" Name="LaterLabel" />

    </StackPanel>

     

    En de code behind:

    private void comboBox1_SelectionChanged(object sender, RoutedEventArgs ea)
    {
        LaterLabel.Content = "maakt niet uit";
    }

    Door het specificeren van de SelectedIndex property, gaat het SelectionChanged event meteen af.

    En de eerste keer bij het renderen van dat control bestaat de label nog niet. Dus je krijgt een Null ref exception.

     

    Mogelijke oplossingen (in volgorde van mijn persoonlijke voorkeur):

    1. Checken of de control null is (dit zou eigenlijk altijd moeten)
    2. De SelectedIndex zetten na de InitializeComponent() in de constructor
    3. Het event in code koppelen na de InitializeComponent() in de constructor
    4. De label control eerder definieren in xaml

    Overigens is dit geen bug. Het is gewoon een valkuil waar je rekening mee moet houden. (net als bij Asp.Net)

     

    Dit stuk is gebaseerd op het artikel van Josh Smith

  • Gratis MSDN InTrack: User Experience

    Deze InTrack geeft inzicht in de manier waarop Microsoft naar user experience kijkt en gaat met name in op Silverlight. Met behulp van presentaties en demonstraties wordt er een overzicht gegeven van de manier waarop Silverlight ingezet kan worden. Tevens wordt getoond hoe de samenwerking tussen designers en developers in zijn werk gaat.

    Info