head.WriteLine()

Artikel über TT.UIA & TT.DataForm in der aktuellen dotnetpro

2011-11-10T15:32:00.001+01:00

In der aktuellen Ausgabe der dotnetpro (12/2011) ist mein Artikel “Kurz angemerkt: Aspektorientierte UI-Entwicklung mit Data Annotations” erschienen. Dies ist der dritte Teil einer dreiteiligen Artikelserie in denen ich die technischen Aspekte von Thinktecture UIAnnotations und Thinktecture DataForm erkläre.

Aus dem Abstract:

Moderne Softwareoberflächen sollen ansprechend, einheitlich und einfach zu bedienen sein. Eine große Herausforderung – zumal längst nicht jeder Entwickler auch ein guter UI-Designer ist. Metadaten bieten die Möglichkeit, Oberflächen zur Laufzeit nach einheitlichen Richtlinien zu erzeugen, und erlauben es darüber hinaus, die Anzeige zu lokalisieren und Eingaben zu prüfen.

Artikel über TT.UIA in der aktuellen dotnetpro

2011-10-22T12:44:00.001+02:00

In der aktuellen Ausgabe der dotnetpro (11/2011) ist mein Artikel “Sauber getrennt und gekapselt – Aspektorientierte UI-Entwicklung mit Behaviors” erschienen. Dies ist der zweite Teil einer dreiteiligen Artikelserie in denen ich die technischen Aspekte von Thinktecture UIAnnotations erkläre.
Aus dem Abstract:

Das Entwurfsmuster MVVM trennt klar zwischen Oberfläche und Logik. Um auch noch die UI-Interaktionslogik in wiederverwendbare Form zu bringen, per Markup zuweisbar zu machen und trotzdem noch MVVM-konform zu bleiben, sind Behaviors und Trigger das richtige Mittel. dotnetpro zeigt, wie sie funktionieren.

Slides & Samples von der BASTA!

2011-10-01T12:01:00.001+02:00

Die BASTA! hat wieder mächtig Spaß gemacht. Einen Dank an die Teilnehmer meiner Sessions! Hier das Material:

Die BASTA! geht wieder auf Tour

2011-09-19T13:07:00.001+02:00

Zum zweiten Mal in diesem Jahr geht die BASTA! auf Tour.

Vom 21.-23. November geht es in Düsseldorf wieder um “Architecture & Good Practices”.

Architektur, WPF, WCF, Entity Framework, jQuery, ASP.NET...

Die BASTA! on Tour - Architecture & Good Practices ist das Tochterevent der BASTA! - der größten unabhängigen .NET-Konferenz im deutschsprachigen Raum. Drei Tage lang bietet Ihnen dieses große Trainingsevent insgesamt sechs Power Workshops, acht Sessions und ein Speaker Panel zu den Themen Architektur und Best Practices in der .NET-Entwicklung. Die BASTA! on Tour richtet sich an Softwarearchitekten, Projektleiter und Entwickler, die erstklassiges Know-how für geschäftskritische Projekte erhalten möchten… (mehr gibt’s hier)

Ich übernehme dabei wieder die Client-Themen:

Darüber hinaus bestreite ich einen ganztägigen Workshop über die WPF. Am dritten Tag gibt es diesmal zwei zusätzliche Workshops, in denen je einen Web und eine Desktop-Anwendung live entwickelt werden.

Vielleicht sieht man sich ja :)

Slides & Samples von der NRWConf

2011-09-19T12:56:00.001+02:00

Die NRWConf hat auch in diesem Jahr wieder mächtig Spaß gemacht. Einen Dank an die Teilnehmer meiner Session! Hier das Material:

Dynamische UI-Generierung mit WPF und Silverlight

TT.DataForm: MVVM Support

2011-08-25T07:47:00.000+02:00

Bei der Entwicklung von TT.DataForm habe ich besonderen Wert auf den MVVM-Support gelegt. Dies betrifft sowohl die Datenbindung, als auch die Operationen die der Benutzer über die Oberfläche auslösen kann. Hierfür stehen entsprechende Command-Eigenschaften bereit, mit denen einen ViewModel das Control steuern kann.

AddCommand: Legt einen Command für die Neuanlage eines Datensatzes fest.
RemoveCommand: Legt einen Command für das Entfernen von Datensätzen fest.
SelectionButtonCommand: Legt den Command für die Auswahlschaltfläche von Bildern fest.

Für die Navigation stehen keine separaten Commands zu Verfügung, da diese idealerweise über eine entsprechende die Datenquellen-View, wie ICollectionView oder IEditableCollectionView gesteuert werden können.

In manchen Fällen muss das ViewModel jedoch aktiv mit der DataForm kommunizieren. So sollte zum Beispiel vor dem Speichern der Änderungen die aktive Eingabe abgeschlossen werden, um den gerade eingegebenen Wert in die Datenquelle zu übertragen. Hierfür stellt DataForm die Methode AcceptChanges().

Da das ViewModel jedoch nicht direkt mit der Komponente kommunizieren kann, werden die wichtigsten Methoden in einem so genannten ActionCommand abstrahiert. Hierbei stellt das ViewModel eine Eigenschaft vom Typ ActionCommand zu Verfügung, die an die gleichnamige Eigenschaft der DataForm gebunden wird. Daraufhin kann das ViewModel über die ExecuteAction()-Methode die entsprechende Methode auf dem Command aufrufen, welche daraufhin an die DataForm weitergeleitet wird. ExcuteAction() nimmt den Typ der Methode in Form eines Wertes der DataFormAction-Enumeration entgegen. Die folgenden Werte stehen hierbei zu Verfügung:

AcceptChanges: Übernimmt die über die Oberfläche durchgeführten Änderungen.
DetachDataSource: Entfernt die Datenquelle und die zugehörigen UI-Elemente aus dem Control.
Reset: Erstellt die Oberfläche anhand Datenquelle neu.
SetBusy: Sperrt die Oberfläche und blendet den BusyIndicator ein.
SetAvailable: Blendet den BusyIndicator aus und entsperrt die Oberfläche.

Das folgende Beispiel demonstriert die Anwendung:

View:
<dataform:DataForm
ActionCommand="{Binding ActionCommand}" />

ViewModel:
…
public ActionCommand ActionCommand { get; set; }
…
private void SaveChanges()
{
this.ActionCommand.ExecuteAction(
DataFormAction.AcceptChanges, null);
this.ActionCommand.ExecuteAction(
DataFormAction.SetBusy, null);
…
}

Der Wert DataFormAction.SetBusy bewirkt hierbei, dass alle Eingabefelder deaktiviert werden und der eingebaute BusyIndicator eingeblendet wird.

Der Wert DataFormAction.SetAvailable beendet die Animation wieder.

Zusätzlich bietet TT.DataForm die folgenden Eigenschaften, mit denen das Verhalten der Oberfläche konfiguriert werden kann.

Eigenschaft	Beschreibung
AllowAddNew	Bestimmt, die Neuanlage eines Datensatzes über das Steuerelement möglich sein soll.
AllowRemove	Bestimmt, das Entfernen eines Datensatzes über das Steuerelement möglich sein soll.
IsReadOnly	Bestimmt, ob das Steuerelement schreibgeschützt dargestellt werden soll.
Error	Liefert den aktuellen Eigabefehler oder einen Leerstring zurück.
HasError	Ruft ab, ob der aktuelle Datensatz Eingabefehler enthält.
IsBusy	Legt fest, ob der Busy Indicator angezeigt werden soll.
BusyIndicatorType	Legt den Typ des Busy Indicators fest. Zur Auswahl stehen Wheel, Dots und Custom. Bei letzterem Wert muss über die Eigenschaft BusyIndicatorTemplate ein benutzerdefiniertes Template bereitgestellt werden.

Das Beispielprojekt, das in den Sourcen von TT.DataForm enthalten ist, zeigt die Verwendung der verschiedenen Mechanismen in einem MVVM-Szenario.

TT.DataForm: UI Customizing

2011-08-24T07:59:00.001+02:00

In diesem Post soll es um die Anpassung der einzelnen UI-Bestandteile von TT.DataForm gehen.
TT.DataForm besteht aus einer Reihe von Unterkomponenten, die über Styles und Templates separat angepasst werden können. Hierzu zählen:

DataFormHeader: Der Kopfbereich des Controls (Titel, Navigation)
Marker: Markierungssymbole (aktives Feld, geändertes Feld, Pflichtfeld, Fehler)
DataFormItem: Ein Feldzeile mit Bezeichner, Eingabeelement, sowie den Markern.
DataFormFooter: Der Fußbereich des Controls (Beschreibungstext, Fehlertext).
BusyIndicator: Der eingebaute BusyIndicator der DataForm.

Die folgende Abbildung zeigt den internen Aufbau:

Hierbei beschreiben die gelben Kästchen die jeweilige Komponente mit ihren Eigenschaften, während die grünen Kästchen die zugehörigen DataForm-Eigenschaften kennzeichnen, mit denen Anpassungen vorgenommen werden können.

Um beispielsweise die Symbole der Navigationsleiste zu ändern, können über HeaderStyle die Eigenschaften des DataFormHeader-Objekts verändert werden.

<dataform:DataForm x:Name="personDataForm">
<dataform:DataForm.HeaderStyle>
    <Style TargetType="dataform:DataFormHeader">
      <Setter Property="Background"
        Value="LightYellow" />
      <Setter Property="MoveFirstImage"
        Value="/Images/Navigation_First.png" />
      <Setter Property="MovePreviousImage"
        Value="/Images/Navigation_Previous.png" />
      <Setter Property="MoveNextImage"
        Value="/Images/Navigation_Next.png" />
      <Setter Property="MoveLastImage"
        Value="/Images/Navigation_Last.png" />
      <Setter Property="AddImage"
        Value="/Images/New.png" />
      <Setter Property="RemoveImage"
        Value="/Images/Delete.png" />
    </Style>
</dataform:DataForm.HeaderStyle>
</dataform>

Darüber hinaus stehen eine Reihe allgemeiner Eigenschaften bereit, mit denen grundsätzliche Entscheidungen des Erscheinungsbilds festgelegt werden können. Die folgende Tabelle zeigt die hierfür wichtigsten Einstellungen:

Eigenschaft	Beschreibung
RowHeight	Bestimmt die Höhe einer Feldzeile.
ColumnSpacing	Bestimmt den Abstand zwischen Anzeigetext und Eingabesteuerelement.
ColumnCount	Legt die Anzahl der anzuzeigenden Spalten fest.
ShowHeader	Bestimmt, ob der Kopfbereich angezeigt werden soll.
ShowFooter	Bestimmt, ob der Fußbereich angezeigt werden soll.
ShowEditTracker	Bestimmt, ob das Symbol für geänderte Felder angezeigt werden soll.
ShowRowMarker	Bestimmt, ob das Symbol für das aktuell fokussierte Felder angezeigt werden soll.
ShowRequiredFieldMarker	Bestimmt, ob das Symbol für Pflichtfelder angezeigt werden soll.
ShowErrorMarker	Bestimmt, ob das Symbol für Eingabefehler angezeigt werden soll.
CornerRadius	Legt den Radius des äußeren Rahmens fest.
ShowDropShadow	Zeichnet einen Schatteneffekt für das Steuerelement.

Noch mehr Beispiele für die Anpassungsmöglichkeiten finden Sie im Demoprojekt, das den Sourcen von TT.DataForm beiliegt.

TT.DataForm: Mappings

2011-08-23T08:12:00.002+02:00

Nachdem ich hier bereits die Data Binding-Mechanismen von TT.DataForm beschrieben habe, soll es in diesem Post um die Anpassung der UI-Generierung gehen. Hierfür stehen zwei Modelle zu Verfügung: Control Mappings und Item Definitions.

Control Mappings

Mit den Control Mappings kann konfiguriert werden, in welcher Form die zu Verfügung gestellten Daten in UI-Elemente umgesetzt werden sollen. Standardmäßig verfolgt TT.DataForm das folgende Mapping:

Datentyp	Input Control
int, double, decimal	NumericUpDown
string	TextBox
DateTime	DatePicker
bool	CheckBox
ImageSource	Image
Sonstige	TextBlock

Um dieses Mapping anzupassen, können ControlMapping-Objekte definiert und über die ControlMapping-Eigenschaft zugewiesen werden. Hierbei stehen die folgenden Möglichkeiten zu Verfügung:

Mapping auf Feldebene
Mapping auf Datentypebene
Definition eines DataTemplate
Angabe von Metadaten

Hier ein paar Beispiele:

<dataform:DataForm.ControlMappings>
<dataform:ControlMapping ControlType="{x:Type TextBox}"
                           BindingPropertyName="Text"
                           DataPropertyName="Id" />
<dataform:ControlMapping DataType="{x:Type sys:String}"
                           ControlType="{x:Type TextBlock}"
                           BindingPropertyName="Text" />
<dataform:ControlMapping DataType="{x:Type sys:DateTime}"
                           IsReadOnly="True"
                           Description="The birthday.">
    <dataform:ControlMapping.ColumnTemplate>
      <DataTemplate>
        <TextBox Text="{Binding Path=Birthday,
                        StringFormat={}{0:dd. MMMM yyyy}}"
                        IsReadOnly="False" />
      </DataTemplate>
    </dataform:ControlMapping.ColumnTemplate>
</dataform:ControlMapping>
</dataform:DataForm.ControlMappings>

In diesem Beispiel wurde festgelegt, dass die Eigenschaft Id als TextBox (statt als NumericUpDown) gerendert und hierbei die Text-Eigenschaft gebunden werden soll. Darüber hinaus wurde festgelegt, dass alle Eigenschaften vom Typ string in Form von TextBlock (statt TextBox) dargestellt werden. Für den Datentyp DateTime wurde zusätzlich festgelegt, dass alle Felder des Typs schreibgeschützt dargestellt werden sollen. Diese Art der Metadatenangabe kann sinnvoll sein, wenn die Datenquelle nicht mit Data Annotations attributiert wurde, bzw. die Angaben überschrieben werden soll. Zuletzt wurde für das Feld Birthday ein eigenes DataTemplate definiert. Dies kann dann sinnvoll sein, wenn das zu erzeugende UI-Control speziell konfiguriert oder das Binding zum Beispiel mit einem ValueConverter versehen werden muss.

Item Definitions

Die Item Definitions erfüllen im Grunde den gleichen Zweck wie die Control Mappings, erlauben hierbei jedoch weitaus mehr Anpassungsmöglichkeiten. So kann zum Beispiel nicht nur das Eingabeelement, sondern auch das Anzeigeelement festgelegt werden. Darüber hinaus können Item Definitions sowohl für gebundene, als auch für ungebundene Felder definiert werden. Das bedeutet, dass die Oberfläche zum Beispiel ein Notizfeld enthalten kann, obwohl die Datenquelle keine entsprechende Eigenschaft bereitstellt.
Die Erstellung von Item Definitions erfolgt über die Eigenschaft DataFormItems. Hierüber können ein oder mehrere DataFormItem-Objekte zugewiesen werden. Diese bestimmen über die Eigenschaften Header und Content den Anzeigetext bzw. das zu verwendende Eingabeelement.
Hier ein Beispiel für die Definition von Item Definitions:

<dataform:DataForm.DataFormItems>
<dataform:DataFormItem Header="ID:">
    <dataform:DataFormItem.Content>
      <controls:NumericUpDown Width="100"
        HorizontalAlignment="Left"
        Value="{Binding Path=Id, ValidatesOnDataErrors=True}"/>
    </dataform:DataFormItem.Content>
</dataform:DataFormItem>
<dataform:DataFormItem>
    <dataform:DataFormItem.Header>
      <TextBlock Text="Name:" />
    </dataform:DataFormItem.Header>
    <dataform:DataFormItem.Content>
      <TextBox Text="{Binding Path=Name}" />
    </dataform:DataFormItem.Content>
</dataform:DataFormItem>
</dataform:DataForm.DataFormItems>

Wie zu sehen ist, kann die Header-Eigenschaft entweder mit einem einfachen Text, oder mit einem beliebigem Control gefüllt werden.

Im nächsten Post geht es um die grafischen Anpassungsmöglichkeiten von TT.DataForm.

TT.DataForm: Data Binding

2011-08-22T10:59:00.002+02:00

Nach der kurzen Einführung hier, gehe ich in den folgenden Posts näher auf die Features von TT.DataForm ein. Den Anfang mache ich mit dem Thema Data Binding.

Datenquellen

Eine Datenquelle bindet man an TT.DataForm über die Eigenschaft DataSource. Hierbei kann eine beliebige Datenquelle angegeben werden – unabhängig davon ob es sich um eine einzelnes Objekt oder eine Liste handelt. Die folgenden Datentypen werden hierbei unterstützt:

System.Object
System.Type
IEnumerable
ICollectionView
CollectionViewSource
ListCollectionView

Darüber hinaus kann TT.DataForm auch mit dem Data Source Windows von Visual Studio verknüpft werden, dass ein direktes Einfügen aus der Toolbox möglich ist.

Metadaten

Die Generierung der Oberfläche erfolgt auf Grundlage von Metadaten, welche die Datenquelle in Form von Data Annotations bereit stellt. So werden zum Beispiel die Labels mit den Anzeigenamen belegt, die über das Display-Attribut angegeben wurden. Beispiel:
using System.ComponentModel.DataAnnotations;
public class Person
{
[Required]
[Editable(false)]
[Display(Name = "ID", Description = "The id of the person.")]
[DisplayFormat(DataFormatString = "#{0}")]
public int Id { get; set; }

[Required]
[StringLength(50)]
[Display(Name = "Fullname",
Description="The full name of the person.")]
public string Name { get; set; }
…
}
Hierbei werden sowohl die Anzeigeattribute, als auch die Formatierungen und Validierungsregeln von TT.DataForm bei der Generierung berücksichtigt.

Lookup-Daten

Oft werden neben der primären Datenquelle zusätzliche Daten, zum Beispiel für ComboBoxen benötigt. Hierfür bietet TT.DataForm die Methode SetAssociationSource(), sowie die Eigenschaft SubDataSources. Mit Ihnen können mit der Hauptdatenquelle verknüpfte Datenquellen angegeben werden. Hierbei wird jeweils der Name der Eigenschaft in der Hauptdatenquelle, sowie die Liste der verknüpften Datenquelle angegeben.
Der folgende Code zeigt ein einfaches Beispiel:
var list = new ObservableCollection<Department>()
{
new Department { Id = 1, Name = "Development" }
}
var persons = new ObservableCollection<Person>()
{
new Person
{
    Id = 1,
    Name = "Jörg Neumann",
    Department = departments[0]
}
};
dataForm.DataSource = persons;
dataForm.SetAssociationSource("Department", departments);
Daraufhin erzeugt TT.DataForm für die Department-Eigenschaft eine Combobox und bindet diese an die angegebene Quelle.

Die Eigenschaft SubDataSources ist empfehlenswert, wenn die Quelle per Markup zugewiesen werden soll und die Anwendung dem MVVM-Pattern folgt. Hierbei muss als Quelle lediglich der Name der entsprechenden ViewModel-Eigenschaft angegeben werden, welche die verknüpfte Datenquelle zu Verfügung stellt.
ViewModel:
class PersonViewModel
{
public ObservableCollection<Person> Persons { get; }
public ObservableCollection<Departments> Departments { get; }
}
View:
<tt:DataForm DataSource = "{Binding Persons}">
<tt:DataForm.SubDataSources>
<tt:SubDataSource
    EntityPropertyName = "Department"
    DataSourcePropertyName = "Departments"/>
<tt:DataForm.SubDataSources>
</tt:DataForm>
Im nächsten Post beschreibe ich, wie das Mapping zwischen Datenquelle und UI-Element beeinflusst werden kann.

Just Released: Thinktecture DataForm

2011-08-19T09:43:00.000+02:00

Thinktecture DataForm ist ein Open Source Control für WPF (eine Silverlight-Version ist in Arbeit), das eine automatische Generierung von formularbasierten Oberflächen ermöglicht. Hierfür analysiert es die übergebene Datenquelle und die hiermit verknüpften Data Annotations. Darüber hinaus kann die Generierung durch ein umfangreiches Customizing-Modell gesteuert werden. Für eine bessere Usability werden kontextsensitive Symbole und Informationen zu den Daten angezeigt (Pflichtfeldmarkierungen, Beschreibungen, Eingabefehler, …). Darüber hinaus kann so gut wie jeder Aspekt der Oberfläche durch Styles und Templates angepasst bzw. ersetzt werden. Die Komponente unterstützt eine Vielzahl verschiedener Datenquellentypen, sowie programmatische und deklarative Validierung. Zudem kann die komplette Funktionalität über Commands gesteuert werden, was einen Einsatz in MVVM-Anwendungen erleichtert.

Die Einzelheiten der Komponente werde ich in nächster Zeit in separaten Posts beschreiben. Darüber hinaus gibt es auf der CodePlex-Site eine Dokumentation. Zudem ist ein Artikel in der dotnetpro in Planung.

Artikel über TT.UIA in der dotnetpro

2011-08-15T16:52:00.002+02:00

In der aktuellen Ausgabe der dotnetpro (9/2011) ist mein Artikel “Aspektorientierte UI-Entwicklung mit Adornern” erschienen. Dies ist der erste Teil einer dreiteiligen Artikelserie in denen ich die technischen Aspekte von Thinktecture UIAnnotations erkläre.
Aus dem Abstract:

Benutzeroberflächen sind mehr als nur einfache Eingabemasken. Das drückt sich unter anderem darin aus, dass Nutzerfreundlichkeit und Interaktivität immer wichtiger werden. Bei der Implementierung stehen hingegen Kapselung und Wiederverwendbarkeit im Vordergrund. Adorner werden beiden Anforderungen gerecht.

TT.UIA for Silverlight

2011-07-13T14:06:00.002+02:00

TT.UIA ist nun auch für Silverlight verfügbar. Es enthält die komplette Funktionalität der WPF-Version. Zusätzlich bringt es separate Behaviors für alle Adorner mit.

Mehr Infos gibt’s hier.

Re-MVPed

2011-07-04T10:41:00.001+02:00

My MVP award for the "Client App Dev" category has been renewed for another year. Thanks!

TT.UIA: Command Behavior

2011-05-25T08:28:00.002+02:00

Wie hier bereits beschrieben, eignen sich Behaviors sehr gut um Problemstellungen rund um MVVM zu lösen. Ein häufiges Problem in diesem Zusammenhang ist der Umgang mit Commands. Sie können lediglich Buttons (und bei WPF auch Menu Items) zugewiesen werden – alle anderen UI-Elemente verfügen nicht über eine Command-Eigenschaft. Zudem wird der Command immer nur über das Click-Event ausgelöst. Auch bezieht sich der Status eines Command stets auf die IsEnabled-Eigenschaft des jeweiligen Controls. All diese Limitationen versucht TT.UIA mit dem Command Behavior zu lösen.

Das Command Behavior

Die Klasse CommandBehavior leitet von TriggerAction<T> ab und kann somit auf beliebige Elemente und deren Events angewendet werden. Beispiel:
<Button>
<i:Interaction.Triggers>
    <i:EventTrigger EventName="Click">
      <behaviors:CommandBehavior
        Command="{Binding OkCommand}"
        PropertyName="Visiblity"
        CanExecutePropertyValue="Visible"
        CanNotExecutePropertyValue="Collapsed" />
    </i:EventTrigger>
</i:Interaction.Triggers>
</Button>
Hier wurde einem Button der CommandBehavior zugewiesen. Bei welchem Event das Command ausgeführt werden soll wurde hierbei über die EventName-Eigenschaft der Klasse EventTrigger angegeben.
Die Bindung zum Command kann daraufhin wie gewohnt über die Eigenschaften Command bzw. CommandParameter zugewiesen werden. Zusätzlich kann über die Eigenschaften PropertyName, CanExecutePropertyValue und ExecutePropertyValue angegeben werden, welche Eigenschaft des zugehörigen Elements auf welchen Wert gesetzt werden soll, wenn der Command aktiv bzw. inaktiv ist. Sollte für das Setzen des Eigenschaftenwertes eine Konvertierung erforderlich sein, kann über die Converter-Eigenschaft ein entsprechender Value Converter angegeben werden.
Darüber hinaus bietet CommandBehavior die Eigenschaft CommandAction. Dies ist ein shortcut für den Fall, dass sich der Status des Commands lediglich auf die Eigenschaft IsEnabled oder Visibility auswirken sollen. Hierbei muss CommandAction lediglich auf den Wert Hide oder Disable gesetzt werden. Hierbei kann die explizite Angabe über PropertyName, CanExecutePropertyValue und ExecutePropertyValue entfallen. Beispiel:
<Button>
<i:Interaction.Triggers>
    <i:EventTrigger EventName="Click">
      <behaviors:CommandBehavior
        Command="{Binding OkCommand}"
        CommandAction="Hide" />
    </i:EventTrigger>
</i:Interaction.Triggers>
</Button>
So, das war es erstmal mit meiner Blog-Serie zu TT.UIA. Als nächstes steht die Silverlight-Portierung an. Stay tuned!

TT.UIA: Adorner Factory Behaviors

2011-05-24T07:57:00.002+02:00

Wie hier und hier bereits beschrieben, haben Expression Blend Behaviors ein paar Limitationen. Hierzu zählt zum Beispiel die Tatsache, dass sie nicht so flexibel wie Adorner sind. So können sie zum Beispiel nur das zugewiesene Element selbst manipulieren und keine zusätzlichen Elemente einfügen. Um diese Limitationen zu umgehen, bietet TT.UIA die Klasse AdornerFactoryBehavior.
Mit ihr kann ein beliebiger Adorner in Form eines Behaviors zugewiesen werden. Beispiel:
<TextBox>
<i:Interaction.Behaviors>
    <behaviors:AdornerFactoryBehavior
AdornerTypeName="Thinktecture.UIAnnotations.ElementTrackerAdorner" />
</i:Interaction.Behaviors>
</TextBox>
Dies hat den Vorteil, dass der Adorner sehr einfach mit Expression Blend zugewiesen werden kann.

Darüber hinaus ist es auch möglich, einen Adorner mehrfach dem gleichen Element zuzuweisen, was mit der Attached Property-Syntax nicht möglich ist.
Die meisten Adorner von TT.UIA verfügen jedoch über zusätzliche Eigenschaften, die nicht generisch über AdornerFactoryBehavior zugewiesen werden können. Daher bietet es sich an, eine entsprechende Ableitung zu erstellen. Ein Beispiel hierfür ist die Klasse CueBannerBehavior. Sie kapselt den CueBannerAdorner in dem sie von AdornerFactoryBehavior ableitet und die Eigenschaft CueBannerText bereitstellt.
public class CueBannerAdornerFactoryBehavior
: AdornerFactoryBehavior
{
protected override Adorner CreateAdorner()
{
    var adorner = new CueBannerAdorner(this.AssociatedObject);
    adorner.CueBanner = this.CueBannerText;
    return adorner;
}
public static readonly DependencyProperty
    CueBannerTextProperty = DependencyProperty.Register(
      "CueBannerText", typeof(string),
      typeof(CueBannerAdornerFactoryBehavior),
      new PropertyMetadata("",
        OnCueBannerTextPropertyChanged));
public string CueBannerText
{
    get { return (string)GetValue(CueBannerTextProperty); }
    set { SetValue(CueBannerTextProperty, value); }
}
private static void OnCueBannerTextPropertyChanged(
    DependencyObject sender,
    DependencyPropertyChangedEventArgs e)
{
    ((CueBannerAdornerFactoryBehavior)sender)
    .OnCueBannerTextChanged(sender, e);
}
private void OnCueBannerTextChanged(
    DependencyObject sender,
    DependencyPropertyChangedEventArgs e)
{
    if (this.Adorner != null && e.NewValue != null)
      ((CueBannerAdorner)this.Adorner)
      .CueBanner = e.NewValue.ToString();
}
}
Hier wurde zunächst die Methode CreateAdorner() der Basisklasse überschieben und hierin der CueBannerAdorner erstellt. Die Property CueBannerText muss nun lediglich an den Adorner durchgereicht werden.
Im nächsten Post geht es mal nicht um grafische Effekte, sondern den sinnvollen Einsatz von Behaviors in MVVM-Szenarien.

TT.UIA: Behavior Factories

2011-05-23T08:17:00.002+02:00

Wie hier bereits beschrieben, haben Expression Blend Behaviors ein paar Limitationen. Hierzu zählt zum Beispiel die Tatsache, dass sie nicht per Style zugewiesen werden können. Um diese Limitation zu umgehen, bietet TT.UIA die Behavior Factories.

Die Klasse BehaviorFactory

Behaviors werden zwar auch über Attached Properties zugewiesen, können aber nicht über einen Style zugewiesen werden. Dies ist per Design so und führt bei jedem Versuch zu einer Exception. Behaviors lassen sich jedoch per Code zuweisen. Diese Möglichkeit nutzt die Klasse BehaviorFactory. Sie stellt die Attached Property BehaviorTypeName zu Verfügung, über die die Typbezeichnung des Behaviors angegeben werden kann. Der so angegebene Behavior-Typ wird daraufhin instanziiert und per Code an das entsprechende Element gebunden.
In folgendem Beispiel wird das Focus Behavior mit Hilfe von BehaviorFactory innerhalb eines Styles zugewiesen:
<Window>
<Window.Resources>
<Style TargetType="TextBox">
<Setter Property="behaviors:BehaviorFactory.BehaviorTypeName" Value="Thinktecture.UIAnnotations.Behaviors.FocusBehavior" />
</Style>
</Window.Resources>
...
</Window>
Da der Style implizit definiert wurde, werden daraufhin alle Textboxen des Fensters mit dem Behavior ausgestattet, ohne das diese explizit zugewiesen werden müssen.
In diesem Fall kann es jedoch vorkommen, das eine bestimmte Textbox des Fensters nicht mit dem Behavior ausgestattet werden soll. Hierfür bietet BehaviorFactory die Attached Property DetachBehaviorTypeName. Sie unterbindet für das zugehörige Element ist Zuweisung des über einen Style definierten Behaviors.
<TextBox
behaviors:BehaviorFactory.DetachBehaviorTypeName=
"Thinktecture.UIAnnotations.Behaviors.FocusBehavior" />

TriggerActionFactory und TargetedTriggerActionFactory

Wenn das betreffende Behavior nicht von Behavior<T>, sondern von TriggerAction<T> oder TargetedTriggerAction<T> ableitet, muss zusätzlich noch der Name des auslösenden Events, bzw. das Zielelement angegeben werden. Hierfür bietet TT.UIA die spezialisierten Klassen TriggerActionFactory und TargetedTriggerActionFactory.
Im nächsten Post geht es ebenfalls um Behaviors. Hier werde ich die Klasse AdornerFactoryBehavior vorstellen, die verwendet werden kann, um beliebige Adorner per Behavior zuzuweisen.

Slides von der BASTA! ON TOUR

2011-05-21T10:16:00.001+02:00

Die erste BASTA! ON TOUR in diesem Jahr hat richtig Spaß gemacht! Hier die Slides meiner Sessions:

TT.UIA: Behaviors

2011-05-20T08:25:00.002+02:00

Wie hier bereits beschrieben, haben Expression Blend Behaviors gegenüber Attached Properties einige Vorteile. Hierzu zählt vor allem die Designer-Unterstützung in Blend. Ein weiterer Vorteil ist jedoch auch die Tatsache, dass Behaviors mit mehreren Elementen verbunden werden können.
Ein einfaches Beispiel:Ein Dialog enthält eine Textbox/Button-Kombination zur Auswahl einer Datei.

Klassischerweise würde man hier im Code-Behind den Dateidialog öffnen und die Auswahl in die daneben stehende Textbox übertragen. Da dies eine Funktionalität ist, die häufiger benötigt wird, bietet es sich an sie zu kapseln. Der Code-Behind-Ansatz ist jedoch auch in MVVM-Szenarien ein Problem. Das Öffnen des Dialogs möchte man jedoch auch nicht im ViewModel hinterlegen, da es sich um UI-Code handelt.

Das Open File Behavior

Mit einem Behavior lässt sich solch eine Funktionalität sehr komfortabel abbilden. TT.UIA bietet hierfür die Klasse OpenFileBehavior. Sie leitet von TargettetTriggerAction<T> ab und kann somit nicht nur ein Element (der Button im oberen Beispiel), sondern auch an ein Zielelement (die Textbox) gebunden werden.
...
<Button
xmlns:i=
    "clr-namespace:System.Windows.Interactivity;
    assembly=System.Windows.Interactivity"
xmlns:behaviors=
    "clr-namespace:Thinktecture.UIAnnotations.Behaviors;
     assembly=Thinktecture.UIAnnotations">

<i:Interaction.Triggers>
    <i:EventTrigger EventName="Click">
      <behaviors:OpenFileBehavior
        TargetName="imageTextBox"
        DialogTitle="Select an image..."
        Filter="PNG Files|*.png" />
    </i:EventTrigger>
</i:Interaction.Triggers>

</Button>

<TextBox x:Name="imageTextBox" />
...
Die Deklaration erfolgt hierbei über die Klasse System.Windows.Interactivity.Interaction, die Teil des Expression Blend SDKs ist.

Das Busy Behavior

Ein weiteres Problem in MVVM-Anwendungen ist der Umgang mit Cursorn und anderen Fortschrittsanzeigen. Denn das ViewModel sollte weder explizit einen Cursors setzen, noch ein entsprechendes UI-Element direkt steuern. In Silverlight löst man dies meist mit dem beliebten (wenn auch hässlichen) BusyIndicator, die per Data Binding an das ViewModel gebunden wird. Hierfür muss die Komponente jedoch zur Entwurfszeit in das Layout des jeweiligen Fensters so eingefügt werden, dass sie im Vordergrund steht. Dies verursacht bei nachträglichen Layout-Änderungen häufig Probleme. Zudem sollte die Bedienung des Fensters verhindert werden, sobald der BusyIndicator aktiv wird.
All diese Herausforderungen versucht die Klasse *BusyBehavior* zu lösen. Sie zeigt eine überdimensionale Eieruhr und legt dabei einen Overlay über das zugehörige Fenster um die Bedienung der Oberfläche durch den Benutzer zu verhindern. Das Busy Behavior kann mit einem beliebigen Element verknüpft werden. Es ermittelt zur Laufzeit das übergeordnete Fenster und fügt sich auf oberster Ebene in den visuellen Baum ein.
<i:Interaction.Behaviors>
<behaviors:BusyBehavior
IsBusy="{Binding IsBusy}" />
</i:Interaction.Behaviors>
Die Steuerung erfolgt über die Eigenschaft *IsBusy*, die zum Beispiel an eine entsprechende Eigenschaft des zugehörigen ViewModels gebunden werden kann. Das Ganze sieht dann zur Laufzeit in etwas so aus:

Das Dialog Button Behavior

Die Klasse DialogButtonBehavior steuert das Verhalten von Dialogschaltflächen. Klassischerweise hat ein Dialog einen Accept- und einen Cancel-Button, womit der Benutzer das Fenster mit Enter bestätigen, bzw. mit ESC abbrechen kann. Hierbei wird das Fenster geschlossen und die DialogResult-Eigenschaft entsprechend gesetzt. All dies fasst DialogButtonBehavior zusammen, wie das folgende Beispiel zeigt:
<Button>
<i:Interaction.Behaviors>
<behaviors:DialogButtonBehavior ButtonType="Ok" />
</i:Interaction.Behaviors>
</Button>
Über die Eigenschaft ButtonType kann das entsprechende Verhalten definiert werden.

Das Focus Behavior

Die Klasse FocusBehavior markiert das fokussierte Eingabeelement mit einer beliebigen Hintergrundfarbe.
<TextBox>
<i:Interaction.Behaviors>
<behaviors:FocusBehavior HighlightBrush="Yellow" />
</i:Interaction.Behaviors>
</TextBox>

So, das war’s erstmal mit den Behaviors von TT.UIA. Im nächsten Post gehe ich auf die Behavior Factories ein, mit denen einige Limitationen der Behaviors behoben werden können.

TT.UIA: Generic Adorner

2011-05-19T17:58:00.002+02:00

Wie hier bereits beschrieben, bringt TT.UIA eine Reihe fertiger Adorner mit. Unter ihnen ist auch der Generic Adorner, mit dem beliebige Elemente als Adorner definiert und mit anderen Elementen verknüpft werden können.
Die Klasse GenericAdorner dient als Platzhalter für beliebigen Content, der frei positioniert werden kann. Die Zuweisung erfolgt hingegen über die Klasse GenericAdorners, welche entsprechende Attached Properties für die Konfiguration bereitstellt.
Das folgende Beispiel demonstriert die Verwendung:
<Window ...>
<Window.Resources>
    <ToolBar x:Key="adornerToolbar">
      <Button ToolTip="Cut" Command="Cut">
        <Image Source="/Images/Cut.png" Stretch="None" />
      </Button>
      <Button ToolTip="Copy" Command="Copy">
        <Image Source="/Images/Copy.png" Stretch="None" />
      </Button>
      <Button ToolTip="Paste" Command="Paste">
        <Image Source="/Images/Paste.png" Stretch="None" />
      </Button>
    </ToolBar>
</Window.Resources>
<TextBox
    am:GenericAdorners.AdornerElement="{StaticResource adornerToolbar}"
    am:GenericAdorners.VerticalAlignment="Top"
    am:GenericAdorners.HorizontalAlignment="Right"
    am:GenericAdorners.Placement="VerticalOuterHorizontalInner"
    am:GenericAdorners.Margin="0,0,0,0"
    am:GenericAdorners.Visible="True"
    am:GenericAdorners.VisibleOnFocus="True" />
</Window>

Hier wurde zunächst eine Toolbar im Resource Dictionary des Fensters definiert, welche als Adorner einer Textbox zugewiesen werden soll. Die Zuweisung erfolgt über die Attached Property GenericAdorners.AdornerElement. Für die Positionierung stehen die Properties HorizontalAlignment, VerticalAlignment und Placement zu Verfügung. Placement gibt hierbei an, ob sich die Position auf den inneren oder äußeren Rahmen des jeweiligen Controls beziehen soll. Die folgende Abbildung zeigt die möglichen Kombinationen:

Über die Eigenschaft VisibleOnFocus kann zusätzlich festgelegt werden, ob der Adorner dynamisch eingeblendet werden soll, wenn das zugehörige Element den Fokus erhält.
In den Beispielen zu TT.UIA ist eine kleine Demo enthalten, die den Einsatz von GenericAdorner zeigt.

Das war’s erstmal mit den Adornern. Im nächsten Post geht es um die Behaviors in TT.UIA.

TT.UIA: Data Annotation Support

2011-05-18T13:14:00.002+02:00

Wie ich hier bereits beschrieben habe, können die Adorner von TT.UIA sehr leicht per Style zugewiesen werden. Doch neben dieser existiert noch eine weitere Möglichkeit die Zuweisung zu automatisieren.
TT.UIA bietet mit Annotations.AttachDataAnnotations eine Attached Property, die auf Root-Ebene zugewiesen wird. Wird sie auf true gesetzt, werden alle Elemente des Fensters oder des User Controls durchlaufen und dessen Datenbindungen analysiert. TT.UIA prüft hierbei, ob die Datenquelle der jeweiligen Bindung über Data Annotations verfügt. Ist dem so, werden für bestimmte Annotations entsprechenden Adorner gesetzt. Hier ein einfaches Beispiel für eine annotierte Datenquelle:
using System.ComponentModel.DataAnnotations;
public class Person
{
[Required]
[Display(Prompt = "Enter the full name!")]
public string Name { get; set; }
}
Hier wurde die Eigenschaft Name als Pflichtfeld markiert und ein entsprechender Prompt-Text hinterlegt.
Das Markup des Fensters könnte nun zum Beispiel wie folgt aussehen:
<Window uia:ApplyDataAnnotations="True">
<TextBox Text="{Binding Person.Name}" />
</Window>
Das Ergebnis sähe hierbei wie folgt aus:

Für das Required-Attribut wurde der Required-Adorner und für den Prompt-Text der CueBanner-Adorner zugewiesen.
Darüber hinaus werden die folgenden Data Annotations von TT.UIA unterstützt:

EditableAttribute.AllowEdit
Setzt die IsEnabled-Eigenschaft des zugehörigen Elements.
RequiredAttribute
Verknüpft das zugehörige Element mit dem Required Adorner.
StringLengthAttribute.MaximumLength
Setzt die MaxLength-Eigenschaft des zugehörigen Eingabesteuerelements (TextBox, ComboBox oder DatePicker).
DisplayFormatAttribute.DataFormatString
Das Format wird dem Binding-Objekt des zugehörigen Elements zugewiesen.
DisplayFormatAttribute.NullDisplayText
Verknüpft das zugehörige Element mit dem CueBanner Adorner.

Darüber hinaus bietet die Annotations-Klasse mit der Attached Property DescriptionDisplayControl die Möglichkeit, Beschreibungstexte die über DisplayAttribute.Description zugewiesen wurden, in einem beliebigen Control anzuzeigen. Beispiel:
Datenquelle:
using System.ComponentModel.DataAnnotations;
public class Person
{
[Display(Description="The name of the person.")]
[Required]
[Display(Prompt = "Enter the full name!")]
public string Name { get; set; }
}
Markup:
<Window uia:ApplyDataAnnotations="True"
uia:Annotations.DescriptionDisplayControl="{Binding ElementName=descriptionLabel}"
uia:Annotations.DescriptionDefaultText="Ready.">
…
</Window>
Ergebnis:

Die Anzeige erfolgt hierbei beim Erhalt des Fokus. Welchen Text das Statuselement anzeigen soll, wenn kein gebundenes Element den Fokus hat, kann über die Eigenschaft Annotations.DescriptionDefaultText festgelegt werden.
Im nächsten Post geht es um den Generic Adorner, mit dem beliebige UI-Elemente als Adorner an andere Element “angehängt“ werden können.

TT.UIA: Adorner

2011-05-17T09:01:00.003+02:00

Nachdem ich im letzten Post die Funktionsweise von TT.UIA vorgestellt habe, soll es nun um die einzelnen Adorner und ihre Anwendung gehen. Doch bevor es losgeht, erkläre ich - zum besseren Verständig - das Prinzip der WPF Adorner noch einmal in ein paar Worten.

WPF Adorner

Bei Adornern handelt es sich um grafische Erweiterungen, die zur Laufzeit mit beliebigen Elementen des visuellen Baums verbunden werden können. Hierbei zeichnet der Adorner über die Oberfläche des zugehörigen Controls, bzw. erweitert dieses um zusätzliche Elemente. Adorner sind Teil von WPF und wurden ursprünglich für die Abbildung von Drag & Drop-Funktionalität entwickelt. Sie eignen sich jedoch auch gut für punktuelle Erweiterungen. So werden sie beispielsweise auch bei der Validierungsfunktionalität von WPF verwendet.

TT.UIA-Adorner

Für die Zuweisung von Adornern bietet TT.UIA die zentrale Klasse Annotations. Sie bietet eine Reihe von Attached Properties, die zur Erstellung von Konfiguration dienen. Beispiel:
<TextBox
uia:Annotations.ShowElementTracker="True"
uia:Annotations.TrackerImageAlignment="Left" />

Hier wurde der ElementTracker-Adorner zugewiesen und über die Eigenschaft TrackerImageAlignment positioniert.

Adorner per Style zuweisen

Die Zuweisung per Attached Property hat den Vorteil, dass kein zusätzlicher Code erforderlich ist und sich die Adorner auch per Style zuweisen lassen. Beispiel:
<Style TargetType="{x:Type TextBox}">
<Setter Property="uia:Annotations.ShowElementTracker"
Value="True" />
<Setter Property="uia:Annotations.TrackerImageAlignment"
Value="Left" />
</Style>
Hier wurde ein impliziter Style definiert, der automatisch allen Textboxen den ElementTracker-Adorner zuweist.

Die Adorner-Sammlung von TT.UIA

TT.UIA bietet eine Reihe vorgefertigter Adorner. Hier eine kurze Auflistung der entsprechenden Attached Properties mit Beschreibung:

HighlightOnFocus markiert das fokussierte Element mit einem weichen Rahmen.
IsRequired markiert ein Pflichtfeld, welches über RequiredImageAlignment positioniert werden kann.
ShowEditTracker markiert Felder, dessen Wert vom Benutzer geändert wurden. Die Position kann über TrackerImageAlignment festgelegt werden.
ShowElementTracker zeigt ein Symbol vor oder hinter dem aktuell fokussierten Element an. Die Position kann über TrackerImageAlignment festgelegt werden.
AttachErrorTemplate verknüpft das Control mit einem Error Template, das im Fehlerfall angezeigt wird.
AttachEditContextMenu verknüpft ein Eingabesteuerelement mit einem erweiterten Editor-Context-Menü.
AttachEditorToolbar verknüpft ein Eingabesteuerelement mit einer Editor-Toolbar.
CueBanner weist dem zugewiesenen Control ein Wasserzeichentext zu.
AttachSmartTag weist dem zugewiesenen Control einen Smart Tag zu. Dessen Menü muss hierbei über die Eigenschaft SmartTagMenu zugewiesen werden.

Eine detaillierte Beschreibung aller Adorner findet ihr in der Dokumentation von TT.UIA, die Implementierungsdetails werde ich in Kürze in der dotnetpro veröffentlichen.
Im nächsten Post geht es um die Möglichkeit Adorner automatisch per Data Annotations zuzuweisen.

TT.UIA: Einführung

2011-05-16T14:36:00.002+02:00

Die Idee hinter thinktecture UIAnnotations (TT.UIA) ist es, UI-Interaktionslogik zu kapseln und diese deklarativ an vorhandene Steuerelemente “anzuhängen”. Der Vorteil liegt hierbei in der flexiblen Anwendbarkeit. Wenn man zum Beispiel eine Textbox mit einem Wasserzeichentext (CueBanner) ausstatten will, gibt es mehrere Möglichkeiten.

Templating: Man erstellt ein Custom Template für die Textbox. Dies ist kein leichtes Unterfangen und ohne Code nur sehr schwer zu realisieren. Zudem muss das Template explizit oder implizit zugewiesen werden.
Vererbung: Hierbei wird eine Ableitung von Textbox erstellt und mit einem Custom Template verknüpft. Bei diesem Ansatz ist alles zwar schön gekapselt, jedoch funktioniert dies nur für Textboxen – Comboboxen, DatePicker und co. sind hiervon natürlich nicht betroffen. Daher müsste man den Vorgang für diese Controls wiederholen. Und wenn dann noch weitere Features implementiert werden sollen, ist man schnell dabei für die komplette Toolbox Ableitungen zu erstellen.

Noch schwieriger wird es, wenn die Erweiterungen nicht nur das Control selbst betreffen. Wenn zum Beispiel neben allen Input Controls, die an Pflichtfelder gebunden sind, ein entsprechendes Symbol erscheinen soll, müssten für alle Control-Typen Custom- oder User Controls erstellt werden.
Aus diesen (und vielen weiteren) Gründe liegt es nahe, die entsprechende Funktionalität mehr oder weniger Control-neutral abzubilden und diese dann im jeweiligen Fall an das gewünschte Control “anzuhängen”. Beispiel:
<TextBox uia:CueBanner="Enter your name!" />

In diesem Beispiel wird von TT.UIA ein WPF Adorner erzeugt, der direkt auf die Oberfläche des entsprechenden Controls zeichnet. Dies hat den Vorteil, dass keine Ableitung des Controls erforderlich ist. Zudem kann der Adorner auch außerhalb des Controls zeichnen, was eine leichte Kennzeichnung von Felder (Pflichtfeld, …) ermöglicht.
Für das “Anhängen” von UI-Funktionalität bietet TT.UIA zwei verschiedene Ansätze: Attached Properties und Expression Blend Behaviors. Beide Varianten haben Ihre Vor- und Nachteile.

Attached Properties bestechen durch ihre Einfachheit. Wie im oberen Beispiel dargestellt, können Sie sehr leicht an ein beliebiges Control angehängt werden. Doch der eigentliche Vorteil – gegenüber Behaviors – ist, dass sie auch per Style zugewiesen werden können.
Expression Blend Behaviors sind vor allem für Designer bzw. alle die vornehmlich in Expression Blend entwickeln interessant. Denn Blend bietet eine sehr gute Designer-Unterstützung für Behaviors. XAML-lastige Entwickler mögen sie wegen ihrer ausladenden Syntax hingegen eher weniger. Der wirkliche Vorteil gegenüber Attached Properties ist jedoch, dass man sie mit Events verknüpfen kann.

Hier ein Beispiel für die Deklaration eines TT.UIA-Behavior.
<TextBox>
<i:Interaction.Behaviors>
<behaviors:FocusBehavior HighlightBrush="Yellow" />
</i:Interaction.Behaviors>
</TextBox>

Hier wird das FocusBehavior verwendet, welches das fokussierte Control in einer beliebigen Farbe einfärbt.
Im nächsten Post stelle ich die einzelnen Adorner und Behaviors von TT.UIA im Detail vor.

Just Released: thinktecture UIAnnotations

2011-05-09T20:32:00.003+02:00

Nach mehr als einem Jahr bin ich nun endlich mit meinem UIAnnotations-Projekt fertig!
thinktecture UIAnnotations

With thinktecture UIAnnotations you can extend your UI with additional functionality via Adorners and Behaviors. All parts are assignable via markup, which is helpful in MVVM scenarios and promotes the developer/designer interaction.
With thinktecture UIAnnotations you can declarative attach visual Adorners and Expression Blend Behaviors to your user interfaces, including smart tags, editor toolbars and visual state markers for required fields, edit states and more. It also can automatically attach adorners to elements while reflecting the Data Annotations of the associated data sources. For a better MVVM support it offers a generic command behavior that is assignable to every event of a given element. thinktecture UIAnnotations is available for WPF and Silverlight (comming soon).

thinktecture UIAnnotations in brief:

10+ useful adorners and 5+ Expression Blend Behaviors.
automatic assignment of adorners via Data Annotations.
a custom adorner model for silverlight (comming soon).
GenericAdorner allows to attach every element as an adorner.
AdornerBehaviorFactory that can be used to wrap every adorner as an Expression Blend Behavior.
BehaviorFactory allows the assignment of Expression Blend Behaviors via styles.
with Command Behavior you can map every control event to a command.

Und da ein Bild mehr sagt als tausend Worte:

Die Details folgen in späteren Posts. Stay tuned!

Artikel in der aktuellen dotnetpro

2011-04-18T12:58:00.001+02:00

In der aktuellen Ausgabe der dotnetpro (5/2011) ist mein Artikel “Die Qual der Wahl: UI-Technologien im Vergleich” erschienen.

Aus dem Abstract:

Für UI-Entwickler wird die Lage zunehmend verwirrender: Da gibt es das gute alte Windows Forms, die Windows Presentation Foundation und Silverlight, und seit Neuestem entbrennt eine Diskussion über das kommende HTML5. Die spannende Frage ist nun: „Auf welche Technologie setze ich als Entwickler in Zukunft?“

TT.DOM Update & Silverlight-Version

2011-03-28T15:35:00.002+02:00

Nach einer längeren Pause habe ich mich mal wieder um mein TT.DOM-Projekt gekümmert:

Mehr Infos gibt’s hier.

Die BASTA! geht wieder auf Tour

2011-02-28T11:13:00.001+01:00

Auch in diesem Jahr geht die BASTA! wieder auf Tour. Die erste Station in diesem Jahr ist Düsseldorf.

Vom 19.-20. Mai geht es um “Architecture & Good Practices”.

Insgesamt zwei Tage lang bietet Ihnen die BASTA! on Tour – Architecture & Best Practices vier Power Workshops, acht Sessions und ein Speaker Panel mit erstklassigem Know-how zum Thema Architektur und Best Practices in der .NET-Welt. Die bekanntesten Architekturproﬁs zeigen Ihnen wie Sie eine Anwendung professionell aufbauen, welche Strategien besonders erfolgreich sind, welche Stärken und Schwächen verschiedene Technologien haben oder wie Sie bei der Implementierung konkret vorgehen sollten.

Ich konzentriere mich in meinen Sessions (wen wundert’s) auf die Clientseite:

Darüber hinaus bestreite ich einen ganztägigen Workshop über die WPF.

Vielleicht sieht man sich ja :)

Weitere Details gibt’s hier.

Slides & Samples von der BASTA! Spring

2011-02-28T10:59:00.001+01:00

Die Spring-BASTA! hat wieder mächtig Spaß gemacht. Einen Dank an die Teilnehmer meiner Sessions! Hier das Material:

Zwei neue SQL Server-Bücher

2010-12-21T13:24:00.001+01:00

Pünktlich zu Weihnachten erscheinen gleich zwei neue SQL Server-Bücher, an denen ich mitgewirkt habe.

Bei Microsoft Press: “Microsoft SQL Server 2008 R2 - Das Entwicklerbuch” (zusammen mit zusammen mit Georg Urban, Klaus Löffelmann und Alexander Köller)

und bei Galileo Press die 4. Auflage von “SQL Server 2008 R2 - Das Programmierhandbuch” (zusammen mit Dirk Mertins und Andreas Kühnel):

Slides & Samples von der BASTA!

2010-09-27T10:25:00.001+02:00

Auch die Herbst-BASTA! hat wieder mächtig Spaß gemacht. Einen Dank an die Teilnehmer meiner Sessions! Hier das Material:

Slides & Demos von der NRW Conf 2010

2010-09-10T15:27:00.001+02:00

Auch in diesem Jahr war die NRWConf wieder klasse. Hier das Material meiner Session, die ich mit Jürgen Behrens bestritten habe.

WCF Client Patterns

Die BASTA! geht wieder auf Tour

2010-07-22T07:52:00.001+02:00

Zu meiner Freude macht die BASTA! ON TOUR diesmal in Hamburg halt. Vom 15. bis 16. November geht es unter dem Motto "Webanwendungen mit .NET" zwei Tage lang um die Entwicklung von Browser-basierten Anwendungen mit ASP.NET und Silverlight.
Hierbei werde ich die folgenden zwei Workshops bestreiten:

Silverlight Architecture Patterns
Silverlight Tipps & Tricks

Mehr Infos gibt’s auf www.basta-on-tour.de.

Vielleicht sieht man sich ja!

Re-MVPed

2010-07-02T07:52:00.001+02:00

My MVP award for the "Client App Dev" category has been renewed for another year. Thanks!

TT.DOM in der aktuellen dotnetpro, Teil 4

2010-06-22T12:55:00.002+02:00

In der aktuellen Ausgabe der dotnetpro (7/2010) ist der vierte und letzte Teil meiner Artikelserie über die Entwicklung von Datenklassen erschienen. Hierin geht es um den Einsatz von TT.DOM in verteilten Anwendungen.
Aus dem Abstract:

In verteilten Anwendungen überschreiten Objekte die Prozessgrenze. Dies stellt den Entwickler vor einige Herausforderungen. Dabei spielen nicht nur Themen wie Serialisierung, sondern auch Änderungsverfolgung, Synchronisation und Konkurrenzbehandlung eine Rolle. Darüber hinaus sind Zugriffsrechte sowie kommunikationsspezifische Eigenheiten nicht zu unterschätzen.

TT.DOM in der aktuellen DevDorado

2010-06-01T10:58:00.002+02:00

In der aktuellen Ausgabe der DevDorado (2/2010) ist mein Artikel “Thinktecture.DataObjectModel: Vermittler zwischen den Welten” erschienen. Aus dem Abstract:

Bei der Entwicklung verteilter Anwendungen kommen verschiedenste Technologien zum Einsatz: WCF für die Kommunikation, ein O/R-Mapper für den Datenzugriff, eine Clienttechnologie zur Präsentation und vieles mehr. Das Zusammenspiel funktioniert jedoch nicht immer reibungslos. Besonders bei den Datenobjekten treffen teilweise gegensätzliche Anforderungen aufeinander. Mit dem Thinktecture.DataObjectModel steht ein Open-Source-Framework zur Verfügung, das zwischen den Welten vermittelt und vor allem auf Clientseite eine Menge fehlender Funktionalität nachrüstet.

TT.DOM in der aktuellen dotnetpro, Teil 3

2010-05-20T11:19:00.002+02:00

In der aktuellen Ausgabe der dotnetpro (6/2010) ist der dritte Teil meiner vierteiligen Artikelserie über die Entwicklung von Datenklassen erschienen. Hierin beschreibe ich das View-Modell von TT.DOM.
Aus dem Abstract:

Benutzer schätzen es, Darstellungen von Daten individuell anpassen zu können – sortieren oder filtern, Spalten ausblenden oder berechnete Spalten anzeigen. All dies erlaubt normalerweise die DataView-Klasse. Bei eigenen Objekten müssen Sie sich selbst um solche Anforderungen selbst kümmern. Das Thinktecture.DataObjectModel hilft auch hierbei.

Slides von der BASTA! ON TOUR

2010-05-20T10:02:00.001+02:00

Hier die Slides meiner Sessions von der BASTA ON TOUR:

Vielen Dank an die Teilnehmer! Das hat Spaß gemacht!

Externe Change Callbacks für Dependency Properties

2010-05-12T09:48:00.001+02:00

Neulich kam in einem Training die Frage auf, wie man einen Change Callback an eine Dependency Property hängen kann. Im konkreten Fall ging es darum auf Eingabeänderungen in einer ComboBox zu reagieren. Da diese jedoch kein passendes Event hierfür vorsieht, muss manuell nachgeholfen werden.
Zwar bieten Dependecy Properties grundsätzlich die Möglichkeit über die Metadaten einen Change Callback einzuhängen, jedoch nur von der Klasse, welche die Property registriert.
Über die Klasse DependencyPropertyDescriptor kann man jedoch auch einen externen Handler einklinken und sich auf diese Weise - auch ohne Event - über Änderungen informieren lassen.
Das ganze funktioniert wie folgt:

DependencyPropertyDescriptor desc =
DependencyPropertyDescriptor.FromProperty(
ComboBox.TextProperty, typeof(ComboBox));
if (desc != null)
{
desc.AddValueChanged(cbx, (s, e) => ... );
}

Aber wie immer gilt: Abmelden nicht vergessen (RemoveValueChanged), damit der Gargabe Collector später aufräumen kann ;)

Die BASTA! geht auf Tour

2010-04-16T10:44:00.001+02:00

Vom 18.-19. Mai findet in München die erste BASTA! ON TOUR unter dem Motto “Architecture & Good Practices” statt.

Das neue Tochterevent der BASTA! legt seinen thematischen Schwerpunkt auf .NET-Architekturen. In zwei Tracks, neun Sessions, vier Workshops und einer Keynote profitieren Sie vom geballten Wissen und der Praxiserfahrung von mehreren der bekanntesten Architektur-Profis der .NET-Welt.

Ich konzentriere mich in meinen Sessions (wen wundert’s) auf die Clientseite:

Darüber hinaus bestreite ich unter dem Titel “Desktop-Anwendungen mit WPF 4.0” einen ganztägigen Workshop am 9. Mai.

Vielleicht sieht man sich ja :)

TT.DOM in der aktuellen dotnetpro, Teil 2

2010-04-09T08:11:00.002+02:00

In der aktuellen Ausgabe der dotnetpro (5/2010) ist der zweite Teil meiner vierteiligen Artikelserie über TT.DOM erschienen. Hierin geht es um das Change Tracking und die Transaktionsunterstützung von TT.DOM.
Aus dem Abstract:

Das Verfolgen von Änderungen in eigenen gebundenen Datenobjekten kann zu einer ziemlich komplizierten
Angelegenheit werden. Das Gleiche gilt für Transaktionen dieser Objekte. Diese sind die Grundlage dafür, Änderungen
von Objekten wieder rückgängig zu machen. Das Framework Thinktecture.DataObjectModel und sein generisches
Datenobjektmodell erleichtern dies.

TT.DOM: Views, Teil 2

2010-03-17T08:30:00.003+01:00

Wie im ersten Teil bereits beschrieben, bietet TT.DOM ein View-Modell, das es ermöglicht beliebig viele Sichten auf eine Liste zu erzeugen. Während es zuletzt um die Möglichkeiten ging, Sortier- und Filterkriterien auf die View anzuwenden, möchte ich in diesem Post beschreiben, wie Sie die Darstellung einer View anpassen und um berechnete Spalten erweitern können.

Views anpassen

Wie hier bereit beschrieben, basiert die Anpassbarkeit der Views auf dem Interface ITypedList. Es definiert die GetItemProperties()-Methode, über die das gebundene Listensteuerelement Informationen über die Spalten der Datenquelle abfragt. Sie gibt eine Collection von PropertyDescriptor-Objekten zurück, welche die jeweiligen Eigenschaften beschreiben. Über einen PropertyDescriptor kann beispielsweise festgelegt werden, welchen Anzeigenamen eine Eigenschaft bei der Bindung annehmen soll, ob diese schreibgeschützt ist oder diese ausgeblendet werden soll. Diese Darstellungsmerkmale ermittelt die PropertyDescriptor-Klasse per Reflection aus der Datenklasse. In der Datenklasse können die Merkmale in Form von Attributen signalisiert werden:
[Browsable(false)]
public string Name { get; set; }
Hierbei können die folgenden Attribute aus dem Namespace System.ComponentModel verwendet werden:

Browsable bestimmt, ob die Eigenschaft angezeigt werden soll.
DisplayName gibt den Anzeigenamen an
ReadOnly steuert den Schreibschutz der Spalte
Description liefert eine Beschreibung der Spalte

Die folgende Abbildung zeigt die Kommunikation zwischen beteiligten Parteien:

Wie hier bereits erwähnt, haben Sie nicht immer Einfluss auf die Datenklasse, sodass Sie unter Umständen die genannten Attribute nicht setzen können. Hierfür bietet DataObjectView<T> die Eigenschaft ColumnAttributes. Sie enthält für jede Eigenschaft der Liste ein DisplayAttributeInfo-Objekt, über das die Darstellung gesteuert werden kann.
DataObjectView<Person> view = list.DefaultView;
view.ColumnAttributes["Id"].Browsable = false;
view.ColumnAttributes["FirstName"].DisplayName = "Vorname";
view.ColumnAttributes["LastName"].DisplayName = "Nachname";
view.ColumnAttributes["LastName"].ReadOnly = true;
Auf diese Weise können Sie die entsprechenden Anzeigeattribute programmatisch zuweisen, ohne die jeweilige Datenklasse anpassen zu müssen. Zudem kann es vorkommen, dass die Darstellung vom jeweiligen Kontext in der Anwendung abhängt.
Neben den genannten Anzeigeattributen bietet DisplayAttributeInfo über die Ordinal-Eigenschaft die Möglichkeit, die Position der Spalte für die Bindung festzulegen. Alternativ können Sie auch die SetOrdinal()-Methode der View verwenden.
list.DefaultView.SetOrdinal(
"Id", "FirstName", "LastName");
Um diese Art der Anpassung auch dem Endanwender zu ermöglichen, bietet TT.DOM einen Standarddialog (CustomizeColumnsForm) mit dem die Darstellung zur Laufzeit angepasst werden kann.

Berechnete Spalten

Über den ITypedList-Mechanismus stellt TT.DOM auch die Möglichkeit zu Verfügung, dynamisch berechnete Spalten zu definieren. Die Spalten werden hierbei über einen eigene PropertyDescriptor-Ableitung bereitgestellt, welche die Werte über einen Delegate ermitteln.
Die Anlage von berechneten Spalten erfolgt über die ComputedColumns-Eigenschaft von DataObjectView<T>. Hierbei geben Sie lediglich den Namen und den Typ der “virtuellen” Eigenschaft, sowie einen Delegate zur Berechnung an.
ComputedColumn col =
new ComputedColumn("FullName", typeof(string),
    item =>
      ((Person)item).FirstName + " " +
      ((Person)item).LastName);
_persons.DefaultView.ComputedColumns.Add(col);
Daraufhin erscheint die Spalte automatisch im gebundenen Listensteuerelement. Das sich der Wert der Spalte automatisch aktualisiert, wenn sich die abhängigen Eigenschaften ändern, brauche ich wohl nicht zu erwähnen ;)
Auch bei dieser Technik besteht der Vorteil vor allem darin, berechnete Spalten bereitzustellen, ohne die zugrunde liegende Datenklasse anpassen zu müssen.

TT.DOM: Views, Teil 1

2010-03-16T09:40:00.003+01:00

Neben der normalen Datenbindungsfunktionalität bietet TT.DOM ein View-Modell, das es ermöglicht mehrere unterschiedliche Sichten auf die selben Daten zu erstellen. So können Sie beispielsweise verschiedene Filter- und Sortierkriterien, oder Anzeigefelder je Sicht definieren.
Hierbei kommen eine Reihe von Standardinterfaces zum Einsatz, die vom jeweiligen Tabellensteuerelement zur Interaktion mit der Datenquelle verwendet werden.

Eine View wird durch die Klasse DataObjectView<T> repräsentiert. Sie implementiert die folgenden Interfaces:

IBindingListView stellt Member für das Filtern und Sortieren bereit. Anders als bei LINQ, werden diese jedoch in Form von Zeichenketten bereitgestellt, was die dynamische Erstellung zur Laufzeit ermöglicht.
ITypedList wird von der Datenbindungsinfrastruktur verwendet, um die anzuzeigenden Eigenschaften der Datenquelle abzufragen. Hierzu stellt die Datenquelle PropertyDescriptor-Objekte zu Verfügung, die um Anzeigeattribute, wie DisplayName, ReadOnly oder Browsable angereichert werden können. Zudem können Sie über diesen Mechanismus berechnete Spalten bereit stellen, die dynamisch erzeugt werden und nicht in Form von Eigenschaften von der Datenklasse bereitgestellt werden müssen.
IListSource wird von der Listenklasse implementiert und verweist auf die Default View. Auf diese Weise wird beim Binden der Liste auf die Default View verwiesen. Dadurch wirken sich Änderungen der Default View direkt auf die Anzeige aus, auch wenn nicht explizit an diese gebunden wurde.

Views erstellen

Für den Zugriff auf eine View stellt DataObjectList<T> zwei Möglichkeiten zu Verfügung:

DefaultView liefert die Standardsicht der Liste. Wie oben bereits erwähnt wird diese durch das IListSource-Interface standardmäßig bei der Binding verwendet.
CreateView() erzeugt eine neue View. Auf diese Weise können Sie beliebig viele Views für die Datenquelle erstellen, wobei Änderungen der Daten – sowohl in der View, auch in der Originalliste – automatisch synchronisiert werden.

Liste sortieren

Für das Sortieren von Daten stellen alle Tabellensteuerelemente entsprechende Funktionen bereit. Es macht jedoch durchaus Sinn diese Funktionalität auch über das Objektmodell anzubieten. So müssen Sie nicht direkt mit dem Tabellensteuerelement kommunizieren, was die Kapselung der Logik und die Austauschbarkeit der Controls erhöht. Zudem stellt .NET mit dem Interface IBindingListView einen Mechanismus bereit, der eine Synchronisation zwischen der Liste und dem Anzeigesteuerelement ermöglicht. Auf diese Weise passt sich die Anzeige automatisch der programmatisch zugewiesenen Sortierung an und umgekehrt.
Die Zuweisung des Sortierkriteriums vollzieht sich bei TT.DOM nach dem gleichen Prinzip wie bei der guten, alten DataView-Klasse: Es wird eine Zeichenfolge mit den Sortierfeldern und optional “ASC” oder “DESC” für aufsteigende bzw. absteigende Reihenfolge festgelegt.
list.DefaultView.Sort = "FirstName ASC, LastName DESC";
Wie bereits erwähnt, bietet die String-basierte Zuweisung den Vorteil, diese zur Laufzeit zuweisen und ändern zu können. Auf diese Weise kann auch der Anwender von der Funktionalität profitieren. Hierfür stellt TT.DOM den Dialog SortForm bereit.

Filter definieren

Das Filtern der Liste erfolgt über die Filter-Eigenschaft der DataObjectView<T>-Klasse.
view.Filter = "LastName LIKE N*";
Hierbei wird der Ausdruck dynamisch via CodeDom nach C# konvertiert, kompiliert und auf die Liste angewendet. Die folgende Abbildung zeigt diesen Prozess:

Bei der Syntax orientiert sich die Funktionalität an den Filterausdrücken, die DataView bietet. Die folgenden Ausdrücke sind hierbei möglich:

Funktion	Beschreibung
Lower()	Wandelt den Text in Kleinbuchstaben.
Upper()	Wandelt den Text in Großbuchstaben.
Str()	Wandelt einen Ausdruck in eine Zeichenfolge.
Trim()	Entfernt Leerzeichen an Anfang und Ende einer Zeichenfolge.
IsNull()	Gibt true zurück, wenn ein Ausdruck den Wert null enthält.
Round()	Rundet eine Zahl auf eine bestimmte Anzahl an Nachkommastellen.
Date()	Wandelt eine Zeichenfolge in ein Datum.
Substring()	Extrahiert eine Teilzeichenfolge an der angegebenen Stelle.
Len()	Gibt die Länge einer Zeichenkette zurück.
Year()	Gibt das Jahr eines Datums zurück.
Month()	Gibt den Monat eines Datums zurück.
Day()	Gibt den Tag eines Datums zurück.
Hour()	Gibt die Stunde eines Datums zurück.
Minute()	Gibt die Minuten eines Datums zurück.
Second()	Gibt die Sekunden eines Datums zurück.
Millisecond()	Gibt die Millisekunden eines Datums zurück.

Damit auch der Benutzer von der Funktionalität profitieren kann, stellt TT.DOM zwei Standarddialoge zu Verfügung – einen für die einfache, Spalten-basierte Filterung und einen Expression Editor für Power User.

Ich könnte mir vorstellen den Filterprozess zukünftig durch Scripting (via dynamic in .NET 4.0) zu ersetzen. Dies würde den komplexen Konvertierungsvorgang überflüssig machen und würde zudem einen reichhaltigeren Sprachumfang bieten.
Wenn sich jemand dazu berufen fühlt, einfach bei mir melden! :)

TT.DOM: Transaktionen

2010-03-15T08:48:00.002+01:00

Wie hier bereit beschrieben, stellt TT.DOM Unterstützung für Undo/Redo-Transaktionen bereit. Darüber hinaus können DataObject-Ableitungen auch an lokalen oder verteilten Transaktionen teilnehmen – ohne dass Sie dafür etwas tun müssen!
Hierfür setzt TT.DOM auf der Funktionalität von System.Transactions auf. So implementiert z.B. die Basisklasse DataObject das Interface IEnlistmentNotification (Prepare, Commit, Rollback, …). Zudem wird sowohl das implizite, als auch das explizite Programmiermodell von System.Transactions unterstützt.
Beispiel für das explizite Enlistment:
Person p = new Person
{ FirstName = "Jörg", LastName = "Neumann" };
CommittableTransaction tran =
new CommittableTransaction();
tran.EnlistVolatile(p);
p.FirstName = "Joerg";
tran.Commit();
Beispiel für das implizite Enlistment:
Person p = new Person
{ FirstName = "Jörg", LastName = "Neumann" };
using (TransactionScope tx = new TransactionScope())
{
p.FirstName = "Joerg";
tx.Complete();
}
Das Ganze kann natürlich auch für auf Listenebene vollzogen und mit anderen transaktionsfähigen Objekten kombiniert werden.

TT.DOM in der aktuellen dotnetpro

2010-03-12T13:39:00.003+01:00

In der aktuellen Ausgabe der dotnetpro (4/2010) ist der erste Teil meiner vierteiligen Artikelserie über TT.DOM erschienen. Hierin geht es zunächst um die Grundlagen von Datenbindung und Eingabevalidierung in Windows Forms, WPF und Silverlight.
Aus dem Abstract:

In verteilten Anwendungen spielen Datenklassen eine zentrale Rolle. Doch um diese zu erstellen, an die Oberfläche zu binden und zwischen den Schichten zu transferieren, müssen einige Hürden genommen werden. Hierbei spielen Datenbindung, Änderungsverfolgung und Transaktionsverwaltung eine zentrale Rolle. Haben Ihnen in der Vergangenheit DataSet und Co. den größten Teil der Arbeit abgenommen, müssen Sie sich bei der Entwicklung eigener Datenklassen um Vieles selbst kümmern. dotnetpro beleuchtet in dieser Artikelserie die wichtigsten Grundlagen und stellt ein Objektmodell vor, das ihnen einen Großteil der Arbeit abnimmt.

TT.DOM: Runtime Proxies

2010-03-11T10:48:00.004+01:00

Bei TT.DOM steckt der Hauptteil der Logik in der Basisklasse DataObject. Von dieser leitet die jeweilige Datenklasse ab und hat dadurch Zugriff auf die Funktionalität. Doch was ist, wenn die Datenklasse bereits von einer anderen Basisklasse ableitet? Dies kann beispielsweise der Fall sein, wenn die Datenklassen in Form eines Entity Framework Modells vorliegen. Vielleicht wollen Sie auf Severseite auch nicht von einer Basisklasse ableiten, um Interoperabilität zu gewährleisten. Ein anderer Fall ist, wenn Sie sich WCF Proxy-Klassen von Visual Studio generieren lassen. In diesem Fall haben Sie keinen Einfluss auf die Basisklasse der Data Contracts.
Für solche Fälle bietet TT.DOM die Möglichkeit, dynamische Runtime Proxies für die Objekte zu erzeugen. Hierbei handelt es sich um Typen, die per Reflection.Emit zur Laufzeit erzeugt werden und einen Wrapper um die Datenklasse bilden.
Ein Runtime Proxy-Typ leitet von DataObject ab und enthält die selben Eigenschaften wie die jeweilige Datenklasse. In den Gettern und Settern der Eigenschaft werden die Anfragen an das Datenobjekt delegiert, welches zuvor im Konstruktor übergeben wurde. Das Ganze sieht dann in etwa wie folgt aus:

Das folgende Beispiel zeigt den Code einer Proxyklasse für die fiktive Klasse Person.
public class Person_Proxy : DataObject
{
private Person _originalObject;

public Person_Proxy(Person person1)
{
    this._originalObject = person1;
}

public string FirstName
{
    get { return this._originalObject.FirstName; }
    set
    {
      base.OnPropertyChanging("FirstName");
      this._originalObject.FirstName = value;
      base.OnPropertyChanged("FirstName");
    }
}
...
}

Proxyliste erzeugen

Die einfachste Art Runtime Proxies zu erzeugen, ist über die Extension Method .ToDataObjectListProxy(), welche auf alle Listen vom Typ IEnumerable angewendet werden kann. Hierbei wird ein Runtime Proxy für den jeweiligen Objekttyp erstellt und die Objekte in eine Liste vom Typ DataObjectList<T> gefüllt. Da T an dieser stelle den jeweiligen Proxy-Typ repräsentiert, können Sie die Liste nicht direkt verwenden (da ja der Proxy-Typ zur Entwurfszeit noch nicht existiert). Stattdessen gibt .ToDataObjectListProxy() eine Instanz von IDataObjectProxyList zurück, über die Sie die Member von DataObjectList<T> ansprechen können.
List<Person> results = personService.GetPersons();
IDataObjectProxyList list = results.ToDataObjectListProxy("Id");
list.BeginEdit();
...

Proxies manuell erzeugen

Zudem besteht auch die Möglichkeit Runtime Proxies manuell zu erzeugen. Hierfür stellt TT.DOM die Klasse ProxyFactory zu Verfügung. Diese stellt Methoden zur Erzeugung von Proxytypen, Objekten und Listen bereit.
// Proxytyp erstellen
ProxyFactory factory = new ProxyFactory();
Type proxyType =
factory.CreateProxyType(typeof(Person), attributes);

// Proxyobjekt erstellen
DataObject obj = (DataObject)
factory.CreateProxy(proxyType, person1);

// Proxyliste erstellen
IDataObjectProxyList proxyList =
factory.CreateProxyCollection(proxyType, sourceList);

// Objekt der Liste hinzufügen
Person p = new Person() { FirstName = "Jörg" };
factory.Add(proxyList, p, typeof(Person));
Bei der Erstellung eines Proxytyps können Sie zusätzliche Anzeigeattribute, wie Browsable, ReadOnly, oder DisplayName angeben, mit denen die Eigenschaften des Proxytyps entsprechend dekoriert werden. Hierdurch können Sie Einfluss auf die Datenbindung nehmen (wie hier beschrieben). Zudem können Sie programmatisch Validierungsregeln einbringen, die von der Proxyklasse über das Interface IDataErrorInfo abgebildet werden, doch dazu mehr in einem separaten Post.

Verwendung der Proxyobjekte

Die Verwendung der Runtime Proxies bietet sich vor allem in Szenarien an, in denen die Objekte vor allem an die Oberfläche gebunden werden. Beim programmatischen Zugriff ergeben sich einige Besonderheiten. Da der Proxytyp nicht von der Datenklasse ableitet, können Sie nicht auf diese casten, was zur Folge hat, dass Sie nicht typisiert auf dessen Eigenschaften zugreifen können. Stattdessen bieten DataObject und IDataObjectProxyList entsprechende Zugriffsmethoden an.
DataObject.GetValue(string propertyName);
DataObject.SetValue(string propertyName, object value);
Alternativ können Sie sich aber auch das zugehörige Datenobjekt ermitteln.
Person p = proxyList.GetDataObject(0);
string firstName = p.FirstName;
Dies bietet sich besonders beim lesenden Zugriff an. Der schreibende Zugriff sollte jedoch immer über die SetValue()-Methode durchgeführt werden, da nur in diesem Fall die Änderung vom Change Tracking bzw. von der Undo-/Redo-Funktionalität berücksichtigt wird.
Das ist der Preis, den Sie für die Flexibilität zahlen müssen ;)

Ableitung vs. Delegation

Das TT.DOM-Proxyverfahren unterscheidet sich von den üblichen Proxy-Generierungskonzepten. So leiten z.B. die Proxies von EF4 direkt von der jeweiligen Datenklasse ab und delegieren die Änderungen an einen zentralen State Manager weiter. Dies hat den Vorteil, dass Sie die Proxies auf den Typ Ihrer Datenklasse casten und somit typisiert auf dessen Eigenschaften zugreifen können.
Damit dieses Verfahren jedoch funktioniert, muss die Datenklasse sämtliche Eigenschaften als virtual definieren. Da dies jedoch nicht immer vorausgesetzt werden kann und auch nicht vom WCF Proxy Generator unterstützt wird, habe ich mich bei meiner Implementierung dagegen entschieden. Zudem ist es auch beim EF4-Ansatz zwingend erforderlich neue Objektinstanzen über eine Factory zu erzeugen, um Change Tracking zu gewährleisten.

TT.DOM: Change Tracking

2010-03-10T16:55:00.002+01:00

Wie im letzten Post bereits beschrieben, stellt TT.DOM mit der Basisklasse DataObject eine Reihe von Datenbindungsfunktionen bereit.
Darüber hinaus ist DataObject aber auch in der Lage, automatisch die Originalwerte der geänderten Eigenschaften eines Objekts zu speichern. Dies ist vor allem für eine spätere Datenbankaktualisierung hilfreich. Die Änderungsverfolgung muss jedoch explizit aktiviert werden, um zu vermeiden, dass Änderungen bereits beim Befüllen der Objekte protokolliert werden. Hierfür bietet DataObject und DataObjectList<T> die Methode BeginEdit().
List<Person> persons = service.GetPersons();
var list = persons.ToDataObjectList("Id");
list.BeginEdit();
Zudem kann die Änderungsverfolgung auch durch Setzen der Mode-Eigenschaft auf Objektebene festgelegt werden.
Um festzustellen, welche Datenobjekte geändert wurden, können Sie die State-Eigenschaft abfragen. Diese enthält je nach Änderung den Wert Unchanged, Insert, Update oder Delete.
Über die Methode GetChanges() können die geänderten Objekte abgefragt werden.
List<Person> changes = list.GetChanges();
Alternativ können auch Änderungen eines bestimmten Typs abgefragt werden.
List<Person> updates =
list.GetChanges(DataObjectStateType.Update);
Wollen Sie die Änderungen an einen WCF-Service übertragen, können Sie die Methode SaveChanges() nutzen. Diese nimmt drei Function Delegates für die Methoden Update Insert und Delete entgegen.
list.SaveChanges<Customer>(
    c => service.UpdateCustomer(c),
    c => service.InsertCustomer(c),
    c => service.DeleteCustomer(c));
Hierbei wird davon ausgegangen, dass ein WCF-Service Proxy mit folgender Signatur existiert:
public Person UpdatePerson(Person p);
public Person InsertPerson(Person p);
public void DeletePerson(Person p);
Alternativ können Sie auch alle Änderungen an den Service übertragen und serverseitig auf den jeweiligen Änderungstyp filtern.
List<Person> changes = list.GetChanges();
service.UpdatePersons(changes);
Auf Serverseite können Sie daraufhin den Status der Objekte, sowie deren Originalwerte ermitteln.
public List<Person> UpdatePersons(List<Person> changes)
{
foreach (Person p in changes)
{
    switch (p.State)
    {
      case DataObjectStateType.Update:
        var orgValue = p.GetOriginalValue("Name");
        // Datensatz in DB aktualisieren
      …
    }
}
}
Hierbei sollte die Service-Methode nicht nur eine Liste der Objekte entgegen nehmen, sondern auch zurückgeben. Dies ist erforderlich, da auf Datenbankseite z.B. Identity-Werte oder Timestamps vergeben werden, die an den Client zurück synchronisiert werden müssen.
Hierfür können Sie auf Clientseite die Methode MergeItems() aufrufen und die lokale Liste mit der serverseitigen synchronisieren.
List<Person> changes = list.GetChanges();
List<Person> refrehedList =
service.UpdatePersons(changes);
list.MergeItems(refreshedList);
Wenn Sie jedoch oben genannte SaveChanges()-Methode aufrufen, können Sie sich diesen separaten Schritt sparen, da dieser automatisch durchgeführt wird.

Undo/Redo

Neben dem Speichern der Originalwerte, kann DataObject und DataObjectList<T> auch beliebige Änderungen rückgängig machen bzw. wiederholen. Beide Klassen bieten hierfür die Methoden Undo() und Redo(). Darüber hinaus können Sie auch einen benannten Undo-Punkt definieren, zu dem zurückgesprungen werden soll. Hierfür legen Sie zunächst über die Methode SetUndoPoint() einen Punkt an und geben diesem einen beliebigen Namen. Einer Überladung der Undo()-Methode können Sie daraufhin den Namen übergeben und alle bis dahin durchgeführten Änderungen werden entsprechen zurückgerollt.
list.SetUndoPoint("MyUndoPoint");
list[0].Name += "*";
list.Add(new Person() { Name = "Bob" };
list.Remove(1);
list.Undo("MyUndoPoint");
Wenn Sie mitbekommen wollen, ob sich die Undo- oder Redo-Liste geändert hat, können Sie sich auf das UndoListChanged bzw. RedoListChanged-Event anmelden.

TT.DOM: Datenbindung

2010-03-09T07:34:00.002+01:00

Wie hier bereits erwähnt, unterstützt Thinktecture.DataObjectModel (TT.DOM) die Entwicklung flexibler Datenklassen. In den folgenden Posts werde ich die wichtigsten Features des Frameworks vorstellen. Den Anfang mache ich mit dem Thema Datenbindung.
Damit ein Objekt optimal an die Oberfläche gebunden werden kann, sollte die entsprechende Klasse eine Reihe von Interfaces implementieren. Über diese kommuniziert die Datenbindungsinfrastruktur mit den gebundenen Objekten um z.B. Synchronisation, Transaktionssteuerung oder Eingabevalidierung zu realisieren. Die folgende Abbildung zeigt diese Kommunikation:

INotifyPropertyChanged dient zur Synchronisation zwischen Datenquelle und Ziel. Auf diese Weise werden Änderungen, die programmatisch an den Objekten durchgeführt werden, an das gebundene Steuerelement gemeldet, sodass dieses die Anzeige entsprechend aktualisieren kann.
INotifyPropertyChanging dient zur Signalisierung von Änderungen, bevor diese durchgeführt werden. Dies Interface hat keine direkten Auswirkungen für die Bindung, ist jedoch für Change Tracking und Transaktionssteuerung wichtig.
IEditableObject stellt ein transaktionales Verhalten für die Datenbindung bereit. So können Sie beispielsweise mehrere Zellen in einem Grid geändert und per ESC wieder zurück gerollt werden.
IDataErrorInfo ist für die clientseitige Validierung zuständig. So kann der Benutzer bereits während der Eingabe auf fehlerhafte Werte aufmerksam gemacht werden.

Wie Sie sehen, gibt es eine Menge zu tun um eine Datenklassen für die Datenbindung zu optimieren.
Hier kommt TT.DOM ins Spiel. Es definiert die abstrakte Basisklasse DataObject, welche die oben genannten Interfaces implementiert. Sie können nun Ihre Datenklassen von DataObject ableiten und haben fast automatisch die entsprechenden Funktionalitäten. Das Einzige was Sie tun müssen, ist Änderungen an Ihren Properties an die Basisklasse zu melden.
public class Person : DataObject
{
private string _name;
public string Name
{
    get { return _name; }
    set
      {
      base.OnPropertyChanging("Name");
      _name = value;
      base.OnPropertyChanged(“Name”); }
}
}
Wollen Sie zusätzlich Validierungsregeln im Stile von IDataErrorInfo in der Datenklasse hinterlegen, überschreiben Sie zusätzlich den Indexer der Basisklasse und hinterlegen die Validierungsregeln nach folgendem Muster.
public class Person : DataObject
{
...
public override string this[string columnName]
{
    get
    {
      if ((columnName == "" || columnName == "Name") &&
          string.IsNullOrEmpty(this.FirstName))
      {
        return "\"Name\" ist ein Pflichtfeld!";
      }
      return string.Empty;
    }
}
}

Auf diese Weise haben Sie Ihre Klasse ohne viel Aufwand mit Synchronisation, Transaktionssteuerung und Eingabevalidierung ausgestattet.
Wie Sie später noch sehen werden, bietet TT.DOM auch die Möglichkeit die Validierungsregeln programmatisch zur Laufzeit zu hinterlegen.

Listenbindung

Auch auf Listenebene müssen Sie für eine Synchronisation zwischen Datenquelle und Ziel sorgen. In Windows Forms und WPF können Sie hierfür das Interface IBindingList bzw. dessen Standardimplementierung BindingList<T> verwenden. Darüber hinaus stellt TT.DOM die Klasse DataObjectList<T> bereit. Diese leitet von BindingList<T> ab und stellt neben der Datenbindungsfunktionalität Einiges mehr zu Verfügung.
Um das Erstellen und Befüllen von DataObjectList<T> zu vereinfachen, stellt TT.DOM die Extension Method .ToDataObjectList() zu Verfügung. Sie kann auf alle Listen vom Typ IEnumerable angewendet werden.
List<Person> persons = service.GetPersons();
var list = persons.ToDataObjectList("Id");
…
Als Parameter wird der oder die Eigenschaften angegeben, die ein Objekt eindeutig identifizieren. Dies ist für eine spätere Synchronisation mit einem Middle Tier-Service notwendig, doch dazu mehr in einem separaten Post ;)

Just Released: Thinktecture.DataObjectModel

2010-03-07T11:06:00.002+01:00

Bei der Entwicklung verteilter Anwendungen steht man als Entwickler häufig zwischen den Stühlen. Denn je nach Schicht ist man mit teilweise gegenläufige Anforderungen konfrontiert. Dies betrifft vor allem das Domänenmodell:

Aus Sicht der Middle Tier sollten Datenklassen dem POCO- bzw. DTO-Ansatz folgen, um eine möglichst hohe Interoperabilität zu gewährleisten.
Die Datenbankseite interessiert sich hingegen in erster Linie für die Originalwerte der geänderten Objekte, um die Datenkonsistenz bei parallelen Zugriffen gewährleisten zu können. Zudem ist auch Transaktionsunterstützung von Vorteil.
Auf Clientseite sollen die Objekte möglichst einfach gebunden werden können. Darüber hinaus müssen Änderungen verfolgt werden können, um eine spätere Aktualisierung zu gewährleisten. Der Anwender freut sich hingegen über Inline-Validierung und Undo/Redo-Support. Auch das dynamische Erstellten von Sortier- und Filterregeln zur Laufzeit ist sehr beliebt.

Das Problem ist nur, dass die vorhandenen Frameworks (WCF/WPF/EF) keine durchgängige Story für Datenklassen bieten, die allen Seiten gerecht wird.
Daher habe ich in den letzten Monaten an einem Framework gearbeitet, das diesen Missstand beheben soll: Das Thinktecture.DataObjectModel steht nun in einer ersten Betaversion auf CodePlex zu Verfügung.
Die wichtigsten Features:

Support für Data Binding
(inkl. Validierung, Change Tracking und Undo/Redo-Support)
Dynamische Attributierung von Properties
(DisplayName, ReadOnly, Browsable, Ordinal, …)
Implementierung von Views
(inkl. Sortieren, Filtern, Computed Columns, etc.)
Automatische Speicherung von Originalwerten für die Behandlung von Konkurrenzsituationen auf Datenbankseite.
Übertragen von Objekten, inkl. Änderungen an WCF-Services
Unterstützung von System.Transactions. So können alle Objekte automatisch an lokalen oder verteilten Transaktionen teilnehmen.
…

Für die Verwendung kann die entsprechende Datenklasse entweder von einer Basisklasse ableiten, oder sie wird zur Laufzeit über einen Runtime Proxy mit der beschriebenen Funktionalität ausgestattet. Auf diese Weise können zum Beispiel auch Modelle vom Entity Framework oder anderen O/R-Mappern flexibel erweitert werden.
Weitere Informationen finden Sie auf http://dataobjectmodel.codeplex.com. Hier gibt’s nicht nur die Sourcen, sondern auch einige Beispiele für Windows Forms und WPF.
Darüber hinaus erscheint in den nächsten Monaten eine vierteilige Artikelserie in der dotnetpro, in der ich das Framework detailliert beschreiben werde.
Falls Sie Fragen oder Anregungen haben, geben Sie Feedback über das Forum der Codeplex-Seite oder per Mail (joerg neumann at thinktecture de)!

WPF: ICO vs. PNG

2010-03-05T13:20:00.001+01:00

Viele Entwickler verwenden in ihren WPF-Anwendungen noch immer die guten, alten Windows Icons. Diese werden von WPF jedoch nicht optimal gerendert, wie das folgende Beispiel zeigt:

Neben der allgemeinen Unschärfe beim Rendern von Icons, sorgt ein weiterer Umstand für unschöne Ergebnisse: Wenn die Icon-Datei mehrere Icons unterschiedlicher Größe enthält, wählt WPF standardmäßig das Erste aus (meist 16x16 Pixel) und vergrößert es entsprechend.

Stattdessen sollten Sie besser PNG-Bitmaps verwenden. Diese werden nicht nur “sauberer” dargestellt, sondern bieten auch die von Icons bekannte Transparenz.

Für die Konvertierung von ICO nach PNG benötigen Sie jedoch einen leistungsfähigen (und daher meist kostenpflichtigen) Icon-Editor. Haben Sie den nicht, können Sie alternativ auch Power Point verwenden. Und das geht wie folgt:

Konvertieren Sie zunächst die ICO-Datei mit Paint nach PNG.
Dann öffnen Sie diese in Power Point
Klicken Sie im Ribbon “Format” den Punkt “Neu einfärben” und dann “Transparente Farbe bestimmen” an.

Daraufhin selektieren Sie den Hintergrund des Icons und speichern das ganze wieder als PNG-Datei ab.

Problematisch kann es jedoch werden, wenn die Hintergrundfarbe ebenfalls im Symbol selbst verwendet wird, da die entsprechenden Bereich dann ebenfalls transparent dargestellt werden. Daher sollten Sie den Hintergrund ggf. vorher mit einer anderen Farbe füllen.

So richtig schön ist das ganze Verfahren zwar nicht, dafür aber kostenlos ;)

WPF Threading ohne Intellisense

2010-03-02T12:05:00.001+01:00

In meinen WPF-Schulungen kommt es immer wieder zu Verwirrungen bzgl. einiger Methoden, die im Zusammenhang mit Threading zum Einsatz kommen. Daher habe die Problematik hier noch einmal zusammengefasst.

Die Klasse DispatcherObject bietet mit CheckAccess() und VerifyAccess() zwei Methoden, mit denen abgefragt werden kann, ob der Zugriff auf ein Objekt aus dem aktuellen Thread aus möglich ist.

Das Problem ist nur, dass beide Methoden nicht über Intellisense zugreifbar sind! Dies führt dazu, dass viele Entwickler sie nicht kennen. Warum die Methoden nicht angezeigt werden, offenbart ein Blick in den Source Code:

[EditorBrowsable(EditorBrowsableState.Never)]
public bool CheckAccess()
{
…
}

Hier sorgt das EditorBrowsable-Attribut dafür, dass die entsprechende Methode weder in Intellisense, noch im Object Browser angezeigt werden.

Das gleiche gilt übrigens auch für die gleichnamigen Methoden der Dispatcher-Klasse. Darüber hinaus werden alle Überladungen der Methoden Dispatcher.Invoke() und Dispatcher.BeginInvoke() nicht angezeigt, die einen Parameter vom Typ DispatcherPriority definieren.

Interessant ist an dieser Stelle, das die genannten Methoden den Anschein erwecken, als wären sie nicht vorhanden, jedoch ausführlich (inkl. Beispielen) in der MSDN beschrieben werden.

Verstehen muss man das nicht, oder?

API-Design vom Feinsten

2010-02-27T14:23:00.001+01:00

Neulich bin ich in MEF auf eine echte API-Design-Perle gestoßen.
Der folgende Code führt eine Composition der Parts durch:

public partial class MainWindow : Window
{
...
private void Compose()
{
    string path = Path.GetDirectoryName(
      Assembly.GetExecutingAssembly().Location);
    DirectoryCatalog catalog =
      new DirectoryCatalog(path);
    CompositionContainer container =
      new CompositionContainer(catalog);
    container.SatisfyImportsOnce(this);
}
...
}

Das Problem hierbei ist, dass der oben stehende Code nicht in jedem Fall kompiliert werden kann. Schauen wir uns die entscheidende Stelle mal genauer an:

container.SatisfyImportsOnce(this);

Die Methode SatisfyImportsOnce() erwartet einen Parameter vom Typ ComposablePart. Nun leitet die oben deklarierte Klasse MainWindow jedoch nicht von ComposablePart ab. Somit ist schnell klar, warum der Code sich nicht kompilieren lässt – möchte man denken.
Er lässt sich jedoch fehlerfrei kompilieren, wenn man den Namespace System.ComponentModel.Composition eingebunden hat!
Dieser enthält nämlich eine Extension Method, die ebenfalls SatisfyImportsOnce() heißt, jedoch einen Parameter vom Typ object erwartet! CompositionContainer ist jedoch im Namespace System.ComponentModel.Composition.Hosting beheimatet, sodass die Verbindung zur Extension Method nicht unbedingt klar ist.

Ein schönes Beispiel dafür, wie man Sprach-Features dafür nutzen kann, den Entwickler maximal zu verwirren ;)

Slides & Samples von der BASTA! Spring

2010-02-27T12:33:00.001+01:00

Die BASTA! Spring war mal wieder ein echtes Highlight im Konferenzkalender. Vielen Dank an die Teilnehmer meiner Sessions für das positive Feedback!
Die Slides & Samples meiner Sessions findet Ihr hier:

PS: Die BASTA! geht auf Tour. Vom 18. bis 19. Mai findet in München die erste BASTA! on Tour statt. Mehr Infos gibt's hier. Ich werde dort zwei Sessions zum Thema Client Development, sowie einen ganztägigen WPF-Workshop durchführen.

Slides vom .NET Information Day

2009-11-05T10:24:00.001+01:00

Die Slides meiner Session “UI*3: WinForms, WPF und Silverlight im Vergleich” vom .NET Information Day gibt’s hier.

Slides von der Prio

2009-11-05T10:21:00.001+01:00

Wie versprochen, hier die Slides einer Session “Technology Shoot-Out: WinForms vs. WPF vs. Silverlight” von der diesjährigen Prio Conference.

Slides von der Advanced Developer Conference

2009-10-19T09:04:00.001+02:00

Die Slides meiner Sessions von der Advanced Developer Conference finden Sie hier:

Slides von der BASTA!

2009-10-01T12:02:00.001+02:00

Wie angekündigt, hier die Slides meiner Sessions von der BASTA!:

Danke an alle Teilnehmer für das positive Feedback!

dot.NET Code Camp in Bad Ems

2009-08-18T08:40:00.001+02:00

Im Oktober gibt es beim dot.NET Code Camp wieder geballtes Wissen in kompakter Form. Rainer Stropek, Holger Schwichtenberg und ich vermitteln 5 Tage lang die wichtigsten Grundlagen zu C# 3.0, WPF, Silverlight und WCF. Mehr Infos gibt's hier.

Dot.NET Code Camp - .NET 3.5 & C#
26.10.-30.10 in Bad Ems

SQL Server 2008-Buch

2009-08-14T10:18:00.001+02:00

Seit vorletzter Woche ist die neue Auflage meines SQL Server-Buches bei Galileo Press erschienen, das ich zusammen mit Dirk Mertins und Andreas Kühnel geschrieben habe.

Auszug aus dem Klappentext:

Dieses Buch wendet sich an alle Entwickler, die die neue Version der Microsoft-Datenbank nutzen wollen. Im Vordergrund steht die Integration des .NET-Frameworks, das die Programmierung mit den .NET-Sprachen ermöglicht. Vom ersten Datenbankentwurf und den SQL-Grundlagen, der Migration von SQL Server 2000 bis hin zu den neuen Features und konkreten Programmierbeispielen beschreiben die Autoren alles Notwendige, um den SQL Server 2008 als Programmierplattform und Datenmanagement-Server zu nutzen. In der neuen Auflage wurde das Buch aktualisiert und um viele Themen wie Indizierte Sichten, Partionierung von Tabellen, Event Notification unter ADO.NET etc erweitert.

Re-MVPed

2009-07-02T09:26:00.001+02:00

My MVP award for the "Client App Dev" category has been renewed for another year. Thanks!

Slides & Samples von der BASTA Spring

2009-03-02T09:19:00.001+01:00

Die Slides & Samples meiner Sessions von der BASTA! Spring finden Sie hier:

An dieser Stelle nochmal einen Dank an Tobias Richling, der mir bei meiner Custom Controls Session zur Seite stand, da meine Stimme erkältungsbedingt auszufallen drohte.

CSharpCodeProvider and referenced .net 3.5 assemblies

2009-02-14T17:37:00.001+01:00

Yesterday I've been working a little with CodeDom and the CSharpCodeProvider to invoke dynamically created code. Because I'm working with some WCF types in the dynamic code, I've added a reference to System.ServiceModel and some other assemblies.

...
CodeDomProvider codeProvider =
    new CSharpCodeProvider(providerOptions);
CompilerParameters compilerParams =
    new CompilerParameters();
compilerParams.GenerateInMemory = true;
compilerParams.ReferencedAssemblies.Add(
    "System.ServiceModel.dll");
...

CompilerResults results = codeProvider.CompileAssemblyFromDom(
compilerParams, codeUnit);

At runtime, the following exception was returned via the CompilerResults.Error collection:

Metadata file 'System.ServiceModel.dll' could not be found.

I've been wondering, because all other assembly references works fine and the code executed as expected when I don't use WCF types in the dynamic code.

The answer lies in the CSharpCodeProvider class. By default it uses the .net 2.0 compiler and don't knows about the Reference Assemblies folder (c:\Program Files\Reference Assemblies\Microsoft\Framework\...) where the additional .net 3.0 and .net 3.5 assemblies can be found.
To force CSharpCodeProvider to use the .net 3.5 compiler, a special provider option must be set:

Dictionary<string, string> providerOptions =
new Dictionary<string, string>();
providerOptions.Add("CompilerVersion", "v3.5");
CSharpCodeProvider provider =
new CSharpCodeProvider(providerOptions);

Artikel in der aktuellen dotnetpro

2008-11-17T09:10:00.001+01:00

In der aktuellen Ausgabe der dotnetpro (12/2008) ist der dritte Teil meiner dreiteiligen Serie über das Managed Add-In Framework (MAF) erschienen. Aus dem Abstrakt:

Fertig zum Einsatz: Ein Command-Modell für das Managed Add-in Framework

Im zweiten Teil der Serie ging es bereits um die Integration von Windows-Forms-basierten Add-ins. In diesem Teil werden nun Dialoge zur Verwaltung und Aktivierung von Add-ins vorgestellt. Außerdem wird ein Command-Modell entwickelt, welches den Add-ins eine leichte Integration in die Menü- und Toolbars der Anwendung ermöglicht.

Slides & Samples von der Prio

2008-11-12T09:02:00.001+01:00

Die Slides & Samples meiner Sessions von der Prio finden Sie hier:

Artikel in der aktuellen dotnetpro

2008-10-15T08:49:00.001+02:00

In der aktuellen Ausgabe der dotnetpro (11/2008) ist der zweite Teil meiner dreiteiligen Serie über das Managed Add-In Framework (MAF) erschienen. Aus dem Abstrakt:

Windows-Forms-Support für das Managed Add-in Framework
Im ersten Teil der Serie wurden die grundlegenden Elemente des Managed Add-in-Frameworks (MAF) erläutert. Nun geht es um die Entwicklung grafischer Add-ins. dotnetpro rüstet die fehlende Unterstützung für Windows-Formsbasierte Add-ins nach. Auf diese Weise können auch Bestandsanwendungen von dem neuen Modell profitieren.

Slides & Samples von der ADC

2008-10-15T08:39:00.001+02:00

Die Slides & Samples meiner Sessions von der Advanced Developer Conference finden Sie hier:

Slides & Samples von der BASTA

2008-09-27T13:24:00.001+02:00

Die Slides & Samples meiner BASTA-Sessions finden Sie hier:

Slides & Samples von der NRW08

2008-09-16T08:57:00.001+02:00

Die Slides und Samples meiner Session Occasionally Connected Clients finden Sie hier.

Artikel in der aktuellen dotnetpro

2008-09-11T09:25:00.001+02:00

In der aktuellen Ausgabe der dotnetpro (10/2008) ist der erste Teil meiner dreiteiligen Serie über das Managed Add-In Framework (MAF) erschienen. Aus dem Abstrakt:

Dynamisch erweitern: Das Managed Add-in Framework in .NET 3.5
Es ist gar nicht so einfach, erweiterbare Anwendungen zu entwickeln. Das Spektrum der Aufgaben reicht vom Auffinden der Add-ins über die dynamische Bindung bis hin zu Versionierung und Absicherung. Für all diese Aufgaben bietet Microsoft das neue Managed Add-in Framework (MAF), das Teil von .NET 3.5 ist. dotnetpro stellt es vor und beleuchtet seine Stärken und Schwächen.

.NET 3.5-Buch bei Hanser erschienen

2008-08-21T11:26:00.001+02:00

Im August ist beim Hanser Verlag das Buch „.NET 3.5: WPF, WCF, LINQ, C# 2008, VB 2008 und ASP.NET AJAX“ erschienen, das ich zusammen mit Holger Schwichtenberg, Walter Doberenz, Matthias Fischer, Jana Frank, Thomas Gewinnus, Jörg Krause und Patrick A. Lorenz geschrieben habe. Ich habe hierbei den Teil über die Windows Presentation Foundation beigesteuert.

Weitere Infos gibt's hier.

Artikel im dotnet Magazin

2008-08-21T11:19:00.001+02:00

In der aktuellen Ausgabe des dotnet Magazin (9/2008) ist der Artikel „SQL Server Security für Entwickler“ erschienen, den ich zusammen mit Dominick Baier geschrieben habe.

Aus dem Abstract:
Das Rückgrat nahezu jeder modernen Anwendung ist eine Datenbank. Dies bedeutet, dass die Gesamtsicherheit einer solchen Anwendung fest mit der Sicherheit der Daten gekoppelt ist. Aus diesem Grund sollten Entwickler ein Grundverständnis für das Datenbank-Sicherheitsmodell haben sowie die Gegenmaßnahmen für die typischsten Daten-Angriffe kennen.

VIP-Tipp in der aktuellen dotnetpro

2008-08-21T11:06:00.001+02:00

Für die aktuelle Ausgabe der dotnetpro (09/2008) habe ich einen VIP-Tipp beigesteuert.

Im VIP-Tipp stellt ein Experte fünf bis zehn Buchtitel vor, die er persönlich für besonders lesenswert hält. Der VIP-Tipp soll als Entscheidungshilfe für Softwareentwickler bei der Auswahl der passenden Fachlektüre dienen. Die Aktion ist eine Kooperation zwischen der Fachbuchhandlung Lehmanns, dem Seminaranbieter Professional Developer College und der dotnetpro.

Neben der Veröffentlichung in der dotnetpro, werden die empfohlenen Bücher auch auf der Site von Lehmanns (www.lob.de/viptip) beschrieben.

Artikel und Interview in der aktuellen dotnetpro

2008-07-15T09:00:00.001+02:00

In der aktuellen Ausgabe der dotnetpro (08/2008) sind zwei Artikel von mir zum Schwerpunktthema „GUI“ erschienen.

Fenster mit System
Windows Forms hat sich im Bereich der Desktop-Anwendungen als De-facto-Standard etabliert. Doch mit der Windows Presentation Foundation steht bereits ein direkter Konkurrent in den Startlöchern. Kann sich der „Dauerläufer“ in Zukunft behaupten?

Im Rausch der Oberfläche
Mit der Windows Presentation Foundation will Microsoft nicht nur die GUI-Entwicklung auf eine neue Stufe stellen, sondern auch die Grenzen zwischen Desktop und Web überwinden. Doch eignet sich das neue System auch für schnöde Businessanwendungen?

Darüber hinaus wurde ich von der dotnetpro zum Thema „Erweiterbare Anwendungen“ interviewed.

Erweiterbare Anwendungen aufbauen
Das Microsoft Add-in Framework (MAF) ist eine neue Möglichkeit, Anwendungen erweiterbar auf zubauen. Jörg Neumann wird das Framework auf der prio.conference 2008 vorstellen. dotnetpro sprach mit ihm, welche Vor- und Nachteile es bringt.

MVP'ed

2008-07-07T10:47:00.002+02:00

Microsoft has awarded me as MVP in the Client App Dev Category.
Thanks!

Slides & Samples von der Jump!

2008-04-25T09:31:00.001+02:00

Die Slides & Samples meiner Vorträge, die ich auf der Jump!-Konferenz gehalten habe, finden Sie hier:

Update für WindowsFormsAddInProxy

2008-04-22T13:12:00.001+02:00

Neulich machte mich jemand darauf aufmerksam, dass die Pfeiltasten in Input Controls nicht funktionieren, wenn diese vom Add-In bereit gestellt werden.

Der Grund war, dass die entsprechenden Keyboard-Messages nicht per SendMessage() synchronisiert wurden und somit auf Host-Seite hängen blieben.

Ich habe den Bug gefixed und die aktuelle Version hier bereit gestellt.

PS: Wenn Sie mehr über System.AddIn oder meine Windows Forms-Implementierung erfahren möchten, kommen Sie auf dotnetpro Jump!-Konferenz, die am 24.04. in München statt findet. Hier halte ich eine Session zu dem Thema und beantworte gerne Ihre Fragen.

Artikel im devdorado.de-Magazin

2008-03-05T08:45:00.003+01:00

In der aktuellen Ausgabe des kostenlosen devdorado.de-Magazins ist ein Artikel von mir zum neuen SQL Server 2008 erschienen.

Aus dem Abstract:
Vor gerade einmal zwei Jahren lieferte Micorosoft mit dem SQL Server 2005 ein umfangreiches Update seines Datenbanksystems. Die Erweiterungen im SQL Server 2008 fallen aufgrund der kürzeren Entwicklungszeit nicht ganz so üppig aus. Doch auch wenn die ganz großen Neuerungen fehlen, hat Microsoft an vielen Stellen sinnvolle Verbesserungen vorgenommen. Besonders Entwickler profitieren davon.

Slides von der BASTA! Spring

2008-02-29T11:53:00.002+01:00

Auf der BASTA! Spring hatte ich neben einigen Vorträgen auch wieder viel Spaß. Die Slides meiner Vorträge finden Sie hier:

Check for online/offline state correctly

2008-02-16T12:28:00.001+01:00

With the introduction of the System.Net.NetworkInformation namespace in .NET 2.0, you can easily check for the availability of a network. When you want to be notified when the machine gets online or offline, you can add a handler to the NetworkChange.NetworkAvailabilityChanged event.

NetworkChange.NetworkAvailabilityChanged +=
delegate(object sender, NetworkAvailabilityEventArgs e)
{
_isOnline = e.IsAvailable;
};

The problem with this event is, that it isn't triggerd if you have a loopback adapter installed on your machine.

But the NetworkChange class has a NetworkAddressChanged event, that is fired, when the IP-address of one of your network adapters changes. In the handler you can get the available adapters and check the type via the NetworkInterface.NetworkInterfaceType property. Additionally the Networkinterface class has a static LoopbackInterfaceIndex property that gives you the index of the loopback adapter. With that in mind you can implement an online/offline check like this:

NetworkChange.NetworkAddressChanged += delegate
{
_isOnline = false;
NetworkInterface[] adapters =
    NetworkInterface.GetAllNetworkInterfaces();
for (int i = 0; i < adapters.Length; i++)
{
    NetworkInterface adp = adapters[i];
    if (adp.OperationalStatus==OperationalStatus.Up &&
      adp.NetworkInterfaceType !=
      NetworkInterfaceType.Loopback &&
      i + 1 != NetworkInterface.LoopbackInterfaceIndex)
    {
      _isOnline = true;
      break;
    }
}
};

If you want to refresh your UI when the state changes, you must synchronize the threads, because the NetworkAddressChange event calls you from a worker thread. But thanks to the SynchronizationContext class introduced in .Net 2.0 you can easily do that like this: (thanks to Dominick for the hint):

class MyClass
{
SynchronizationContext _syncContext;

public MyClass()
{
_syncContext = SynchronizationContext.Current;
}

...

void MyMethod()
{
...
_syncContext.Post(delegate
{
ToggleOnlineState(isOnline);
}, null);
}

Now you get informed correctly if the machine moves online or offline.

Ein Command-Modell für System.AddIn, Teil 2

2008-01-30T15:34:00.001+01:00

Nachdem ich im ersten Teil bereits mein Command-Modell und dessen Integration in die Host-Anwendung beschrieben habe, soll es nun um die Add-In-Seite gehen.

Während der Aktivierung ruft die AddInHost-Komponente die InitializeCommands()-Methode des Add-In auf. Hierbei wird eine Instanz von ICommandContext übergeben, über die das Add-In Zugriff auf ICommandService und IUIContextService hat. Über diese Interfaces läuft im weiteren Verlauf die Kommunikation. Die folgende Abbildung zeigt den grundlegenden Ablauf.

Das Add-In muss nun zunächst die vom Host angebotene Command-Struktur ermitteln, um sich im Anschluss in diese integrieren zu können.

public override void InitializeCommands(ICommandContext context)
{
// CommandService und UICommandService ermitteln
ICommandService cmdSrv = context.CommandService;
IUICommandService cmdUISrv=context.UICommandService;

// File-Commands ermitteln
ICommand fileCmd = cmdSrv.GetCommand("Host.File");
IUICommand fileUICmd = cmdUISrv.GetUICommand(
fileCommand, UICommandType.MenuCommand);

// Toolbar ermitteln
IUICommand toolbarUICmd = cmdUISrv.GetMainToobar();

...

}

Hier werden die ICommand- und IUICommand-Objekte des File-Menüs, sowie die primäre Toolbar ermittelt. Daraufhin können neue Elemente eingefügt werden:

// "Neu"-Command erstellen
ICommand fileNewCmd = cmdSrv.CreateCommand(
"FirstAddIn.File.New",
fileCmd);

Hierbei werden ein eindeutiger Name, sowie das jeweils übergeordnete Command-Objekt angegeben. Dazu passend können nun entsprechende Menü- und Toolbar-UICommands erstellt werden:

// "Neu"-UICommand erstellen
IUICommand fileNewUICmd = UICmdSrv.CreateMenuItem(
fileNewCmd,
"&Neu",
fileUICmd,
0,
ToolStripItemDisplayStyle.ImageAndText,
UICmdSrv.GetIconArray(Properties.Resources.New));

In diesem Fall wird ein Menüelement erstellt und hierbei das zugehörige ICommand-Objekt, ein Anzeigetext, das übergeordnetes IUICommand-Objekt, ein Index, sowie der Darstellungsstil und ein Symbol angegeben. Da Bilder in Form von Byte-Arrays über die AppDomain-Grenze geschickt werden, müssen sie über die GetIconArray()-, bzw. GetImageArray()-Methode entsprechend konvertiert werden.

Darüber hinaus können zusätzliche Eigenschaften wie Visible, Checked oder ShortcutKeys festgelegt werden.

Die Erstellung von Toolbar-Elementen erfolgt analog, nur dass hierfür die CreateToolbar()-Methode aufzurufen ist. Darüber hinaus können mit der CreateSeparator()-Methode Separatorelemente für Menü und Toolbar erstellt werden.

Wurde ein Command auf Host-Seite aktiviert, so ruft der Host die NotifyCommandExecuted()-Methode des Add-In auf und übergibt hierbei die jeweilige ICommand-Instanz.

Das Add-In kann daraufhin beispielsweise seine Oberfläche anzeigen. Hierfür bietet die CommandContext-Klasse die ShowSurface()-Methode, welche als Parameter eine WindowProxy-Instanz übergeben bekommt (Details hier).

public override void NotifyCommandExecuted(ICommand command)
{
if (command == m_fileNewCommand)
{
m_surface = new Surface();
m_context.ShowSurface(new WindowProxy(m_surface));
}
}

Surface ist ein User Control, welches von AddInSurface ableitet und die Oberfläche des Add-In enthält. Die Einzelheiten dieser Komponente habe ich bereits hier beschrieben.

Die Sourcen inkl. Beispielanwendung gibt's hier.

Ein Command-Modell für System.AddIn, Teil 1

2008-01-30T11:55:00.001+01:00

Nachdem ich hier und hier bereits die Grundlage für erweiterbare Anwendungen auf Basis von Windows Forms gelegt habe, möchte ich nun einen Schritt weiter gehen. Denn die Integration von Add-Ins in die Host-Anwendung macht erst so richtig Sinn, wenn ein gemeinsames Command-Modell existiert, über das eine Bereitstellung von Menü- und Toolbar-Elementen möglich ist.

Im ersten Teil möchte ich zunächst das Modell und die Host-Integration beschreiben, während es im zweiten Teil um die Add-In-Seite gehen soll.

Die Basis des Command-Modells bilden die Interfaces ICommand und UICommand, deren Member in der folgenden Abbildung dargestellt sind:

Während ICommand die allgemeinen Eigenschaften einer hierarchischen Command-Struktur definiert, legt IUICommand die grafische Repräsentation fest.

Hierbei bildet der Host zunächst seine Menü- und Toolbar-Struktur über Commands ab und übergibt diese an die Add-Ins. Diese können sich daraufhin in die Hierarchie integrieren und eigene Commands anbieten. Für die Manipulation der Struktur werden die Interfaces ICommandService und IUICommandService bereitgestellt. Beide werden über ICommandContext zusammengefasst und während der Aktivierung an das Add-In übergeben.

Während mit ICommandService die benötigten Command-Objekte erstellt werden, ist IUICommandService für die Generierung einer grafischen Repräsentation in Form von Menü- und Toolbar-Elementen verantwortlich. Über die ShowSurface()-Methode von ICommandContext hat das Add-In zusätzlich die Möglichkeit seine Oberfläche an den Host zu übertragen (beispielsweise wenn ein Command aktiviert wurde).

Die Kommunikation zwischen Host und Add-Ins erfolgt über das IAddInCommandContract-Interface, welches von der entsprechenden Host-View-Klasse implementiert wird. Zusätzlich findet sich dessen Signatur auch im jeweiligen Add-In-Contract (hier IAddInContract genannt).

Nachdem ein Add-In geladen wurde, ruft der Host die InitializeCommands()-Methode auf und übergibt ein ICommandContext-Objekt. Daraufhin registriert sich das Add-In in der Command-Hierarchie. Beim Auslösen eines Commands informiert der Host das Add-In über die NotifyCommandExecuted()-Methode. Optional hat die Host-Anwendung über die GetSurface()-Methode die Möglichkeit, die Oberfläche des Add-In explizit anzufordern.

Was nun noch fehlt ist eine Komponente die auf Host-Seite die Integration der Commands in die jeweilige Menü- und Toolbar-Struktur übernimmt. Hier kommt AddInHost zum Einsatz. Es leitet von Component ab und kann daher direkt aus der Toolbox auf eine Form gezogen werden. AddInHost bekommt über die Eigenschaften MainMenuStrip und MainToolStrip die primäre Menüleiste bzw. Toolbar übergeben. Zusätzlich kann ihr eine Instanz von WindowProxyPanel übergeben werden, welches zur Darstellung der Add-In-Oberfläche dient (Details hier). Auf diese Weise kann AddInHost nicht nur die entsprechenden Commands in Menü und Toolbar anlegen, sondern die Oberfläche auch automatisch binden, wenn das Add-In dies über ICommandContext.ShowSurface() veranlasst. Zusätzlich bietet die Komponente über die ShowAddInManager()-Methode die Möglichkeit den Add-In-Konfigurationsdialog zu öffnen, der für das Laden und Entladen der Add-Ins zuständig ist (Details hier).

Durch die enge Verzahnung der Komponenten, wird die Implementierung des Add-In-Supports für die Host-Anwendung zum Kinderspiel. Sie muss lediglich die folgenden Komponenten zu Verfügung stellen:

MenuStrip
ToolStrip
WindowProxyPanel
AddInHost

Nachdem alle Komponenten mit AddInHost verbunden wurden, sind lediglich die folgenden Codezeilen erforderlich:

// Add-In-Pfad zuweisen
addInHost1.AddInPath = Environment.CurrentDirectory;

// Add-In-Store erstellen/aktualisieren
AddInStore.Rebuild(addInHost1.AddInPath);

// Registrierte Add-Ins vom Typ AddInHostView ermitteln
addInHost1.AvailableAddIns = AddInStore.FindAddIns(
typeof(AddInHostView), addInHost1.AddInPath);

// Commands für Menü- u. Toolbar-Elemente erstellen
addInHost1.CreateCommands();

Hier wird zunächst der Add-In-Store neu erstellt und daraufhin die verfügbaren Add-Ins über AddInStore.FindAddIns() ermittelt. Die zurückgegebene Liste von AddInToken-Objekten kann daraufhin an AddInHost übergeben werden.

Durch den Aufruf von CreateCommands() erstellt AddInHost automatisch entsprechende ICommand- und IUICommand-Objekte für die vorhandenen Menü- und Toolbar-Elemente.

Für die Erstellung eines Commands wird ein eindeutiger Name benötigt, über den das Add-In später Referenzieren kann. Hierfür stellt AddInHost die Extender Property CommandName bereit. Sie wird automatisch jedem ToolStripItem-Element der Form angehängt und ermöglicht so eine leichte Zuordnung.

Darüber hinaus können gleichartige Menü- und Toolbar-Elemente unter einem Command zusammengefasst werden. Wenn ein Add-In beispielsweise den Command "Host.File.New" deaktiviert (Command.Enabled-Eigenschaft), wird sowohl das Menü, als auch der zugehörige Toolbar-Button automatisch deaktiviert.

Zusätzlich abonniert AddInHost das Click-Event des jeweiligen Elements und informiert seinerseits über das CommandExecuted-Event über dessen Aktivierung. Daher benötigen Sie lediglich einen Event Handler für alle Menü- und Toolbar-Elemente.

Das Öffnen des Add-In-Manager-Dialogs kann beispielsweise über einen Menüpunkt erfolgen und durch den folgenden Event Handler verarbeitet werden:

private void addInHost1_CommandExecuted(
    object sender, CommandExecutedEventArgs e)
{
if (e.Command.Name == "Host.Extras.AddInManager")
{
    // Add-In-Manager-Dialog anzeigen
    addInHost1.ShowAddInManager(this, false);
}
}

Der Dialog kümmert sich nun automatisch darum, die vom Benutzer ausgewählten Add-Ins zu aktivieren und über die InitializeCommands()-Methode die entsprechenden Commands anzufordern. AddInHost integriert daraufhin die bereitgestellten Commands in Menü und Toolbar und somit schließt sich der Kreis.

Für den Host wird die Sache somit denkbar einfach. Welche Arbeiten auf Add-In-Seite zu verrichten sind, erkläre ich im zweiten Teil.

Sourcen inkl. Beispielanwendung gibt's hier.

Thinktectured'

2008-01-29T10:09:00.001+01:00

Now it's official: I'm joining Thinktecture. I know Christian, Ingo, Dominick and Neno a lot of years and I'm glad to work with these fantastic guys!

Watch my profile for further information.

Let's Rock!

Grafische Verwaltung von Add-Ins

2008-01-21T13:50:00.001+01:00

Wie ich hier bereits beschrieben habe, bietet System.AddIn keine Unterstützung für Windows Forms-basierte Add-Ins. Gleiches gilt auch für die grafische Verwaltung in einer Anwendung. Einen Add-In-Manager-Dialog, wie man ihn aus Visual Studio oder Office kennt, ist zurzeit nicht verfügbar.

Daher habe ich einen generischen Dialog entwickelt, der die Aktivierung und Verwaltung von Add-Ins zur Laufzeit stark vereinfacht. Zusätzlich stelle ich zwei Dialoge bereit, in denen Aktivierungsoptionen eingestellt werden können, bzw. die Informationen über geladene Add-Ins bieten. Diese sind jedoch in erster Linie für den Entwickler und weniger für den Anwender gedacht, doch dazu später mehr.

Da ja bekanntlich ein Bild mehr als tausend Worte sagt, hier die Bestandteile in grafischer Form:

1) AddInManagerForm beinhaltet den eigentlichen Verwaltungsdialog. Für die Darstellung der Add-In-Liste greift er auf das AddInManagerControl zurück. In ihr werden die verfügbaren Add-Ins gelistet.

2) AddInManagerControl ist ein User Control für die Anzeige der verfügbaren Add-Ins, bzw. zu dessen Aktivierung.

3) AddInActivationOptionsForm bietet Steuerungsoptionen zur Add-In-Aktivierung. Hier kann beispielsweise eingestellt werden, ob das Add-In in einer AppDomain oder einem separaten Prozess gehostet werden soll.

4) AddInDetailsForm stellt Informationen über bereits geladene Add-Ins zu Verfügung. Er stellt beispielsweise Informationen über die zugehörige Add-In-Assembly bereit.

Alle Komponenten sind in der WindowsFormsAddInProxy.dll vereint, die ich bereits hier und hier beschrieben habe.

Verwendung

Durch die Verwendung des Add-In-Manager-Dialogs reduziert sich der Code in der Anwendung deutlich, da dieser nicht nur eine grafische Oberfläche bereitstellt, sondern ebenfalls die entsprechende Aktivierung und Deaktivierung übernimmt. Damit dies funktioniert, müssen jedoch einige Voraussetzungen erfüllt sein.

Zunächst müssen zwei Listen geführt werden, die alle verfügbaren, bzw. geladenen Add-Ins enthalten. Diese können beispielsweise als statische Member in der Program-Klasse hinterlegt werden.

static class Program
{
    public static Collection<AddInToken> AvailableAddIns;
    public static AddInDictionary LoadedAddIns;
    public static string AddInPath;

    [STAThread]
    static void Main()
    {
        LoadedAddIns = new AddInDictionary();
        AddInPath = Environment.CurrentDirectory;

        // Vorhandene Add-Ins ermitteln
        AvailableAddIns =
           AddInStore.FindAddIns(typeof(AddInHostView),
           Program.AddInPath);

        Application.EnableVisualStyles();
        Application.SetCompatibleTextRenderingDefault(false);
        Application.Run(new MainForm());
    }
}

Beim Programmstart werden zunächst die verfügbaren Add-Ins in der Main()-Methode ermittelt. Für die Liste der geladenen Add-Ins kommt eine Instanz der AddInDictionary-Klasse zum Einsatz. Diese leitet von Dictionary<AddInToken, IAddInManager> ab und enthält für jedes geladene Add-In ein Token und die entsprechende Instanz. IAddInManger ist ein Marker-Interface, das keinerlei Logik enthält und ausschließlich für den generischen Umgang mit den entsprechenden Add-In-View-Instanzen verwendet wird. Dies ist nötig, da AddInManagerForm keinerlei Informationen über die konkreten View-Klassen hat. Diese müssen nun lediglich von IAddInManger ableiten und können daraufhin generisch verwaltet werden. Im Beispielprojekt sieht die wie folgt aus:

public abstract class AddInHostView : IAddInManager
{
public abstract WindowProxyBase GetSurface();
}

Nach dieser Vorarbeit kann der Dialog aufgerufen werden:

AddInManagerForm frm = new AddInManagerForm();
frm.AddInPath = Program.AddInPath;
frm.AvailableAddIns = Program.AvailableAddIns;
frm.LoadedAddIns = Program.LoadedAddIns;
if (frm.ShowDialog(this) == DialogResult.OK)
{
// ...
}

AddInMangerForm muss nun der Pfad des Add-In-Verzeichnisses, sowie die Liste der verfügbaren und geladenen Add-Ins übergeben werden, alles Weitere übernimmt der Dialog.

Aktiviert nun der Benutzer ein Add-In, wird dieses automatisch geladen und ist im Anschluss über Program.LoadedAddIns verfügbar. In der Beispielanwendung werden die geladenen Add-Ins in eine Liste aufgenommen, über die sie gebunden werden können.

...
if (frm.ShowDialog(this) == DialogResult.OK)
{
    // Liste der geladenen Add-Ins füllen
    this.addInsListView.Items.Clear();
    foreach (AddInToken token in Program.LoadedAddIns.Keys)
    {
        ListViewItem item =
           this.addInsListView.Items.Add(token.Name);
        item.Tag = token;
    }
}

Zum Binden der Oberfläche wird zunächst die entsprechende View-Instanz über Program.LoadedAddIns ermittelt und auf dieser die GetSurface()-Methode aufgerufen.

private void bindAddInButton_Click(object sender, EventArgs e)
{
    AddInToken token =
       this.addInsListView.SelectedItems[0].Tag as AddInToken;
    AddInHostView instance =
       Program.LoadedAddIns[token] as AddInHostView;
    if (instance != null)
    {
        // Oberfläche des selektierten Add-Ins binden
        WindowProxyBase window = instance.GetSurface();
        if (window != null)
        {
            this.windowsProxyPanel1.SetWindow(window);
            this.windowsProxyPanel1.Select();
        }
    }
}

Das Resultat sehen Sie hier:

Zusätzliche Optionen

Wie oben bereits erwähnt, kann die Aktivierung eines Add-Ins durch einen Optionsdialog unterstützt werden. Hier können Hosting-Modell (AppDomain oder Prozess) und der Sicherheitskontext eingestellt werden.

Der Dialog ist jedoch in erster Linie für den Entwickler und Anwendungsbetreuer gedacht und sollte dem Endbenutzer nicht zu Verfügung stehen. Daher kann die Anzeige über die ShowActivationOptions-Eigenschaft der AddInManagerForm-Klasse gesteuert werden.

Wurde die Option deaktiviert, so können Sie über die Eigenschaften AddInActivationType und AddInSecurityLevel der Aktivierungstyp, bzw. der Sicherheitskontext festgelegt werden.

Die Sourcen, inkl. Beispielprojekt finden Sie hier. Für Feedback bin ich wie immer dankbar.

Update von WindowsFormsAddInProxy

2008-01-14T10:15:00.001+01:00

Jesse Kaplan, einer der Architekten von System.AddIn, hat mich darauf aufmerksam gemacht, dass IWindowProxy in meiner Implementierung nicht unbedingt notwendig ist, da in System.AddIn.Contract bereits ein entsprechendes Interface existiert. Daher habe ich IWindowProxy kurzerhand über Bord geworfen und verwende nun statt dessen INativeHandleContract.

Anstelle einer Handle-Eigenschaft, definiert es die GetHandle()-Methode. Das Prinzip bleibt jedoch das Gleiche: Die Übertragung eines Window Handles über die AppDomain-Grenze.

Die aktualisierten Sourcen, inkl. Demo finden Sie hier.

Windows Forms Support für System.AddIn, Teil 2

2008-01-07T15:44:00.001+01:00

Nachdem ich im ersten Teil den grundlegenden Aufbau der WindowsFormsAddInProxy.dll beschrieben habe, soll es nun um die Details der Implementierung gehen. Zum besseren Verständnis der beteiligten Komponenten, hier zunächst einmal der Aufbau der Assembly:

Wie ich im ersten Teil bereits erwähnte, ist das Hauptproblem bei der Übertragung von UI-Elementen über AppDomain-Grenzen, dass Windows Forms-Klassen weder serialisierbar sind, noch per Reference übertragen werden können. Daher wird lediglich das Handle der Add-In-Oberfläche übertragen und auf Host-Seite „umgehängt“. Hierfür stellt die Win32-API die SetParent()-Methode zu Verfügung. Sie nimmt das jeweilige Handle, sowie das Handle des gewünschten Elternfensters entgegen. Die Add-In-Oberfläche wird somit zum Kindelement des entsprechenden Host-Controls.

Aus Sicherheitsgründen ist das Umhängen von Handles jedoch nur innerhalb eines Win32-Prozesses möglich. Somit kann diese Technik nicht eingesetzt werden, wenn die Add-Ins in einem separaten Prozess gehosted werden. Für Client-seitige Add-Ins ist die AppDomain-Isolation jedoch vollkommen ausreichend.

Für das Übertragen des Handle ist das IWindowProxy-Interface zuständig, welches einzig die Handle-Eigenschaft definiert. IWindowProxy kann nun im jeweiligen Add-In-Contract verwendet werden, um Oberflächen-Inhalte über die AppDomain-Grenze zu transferieren. Im Beispielprojekt wird IWindowProxy in der GetSurface()-Methode eingesetzt, mit der der Host die Oberfläche des Add-In ermittelt.

Die eigentliche Kommunikation findet jedoch über die Klassen AddInSurface (Add-In-Seite) und WindowProxyPanel (Host-Seite) statt. Letztere bekommt über die SetWindow()-Methode eine WindowProxyBase-Instanz übergeben und „kapert“ daraufhin das zugehörige Fenster.

public void SetWindow(WindowProxyBase window)
{
    if (window != null && window.Handle != IntPtr.Zero)
    {
        SetParent(window.Handle, this.Handle);
    }
}

Weitere Herausforderungen

Somit ist das Hauptproblem schon mal gelöst. Doch nach einem kurzen Test treten weitere Herausforderungen auf. Da das Umhängen des Handles per Win32-Funktion erfolgte, hat die Windows Forms-Infrastruktur keine Information über die Existenz des Controls. Daher werden viele Nachrichten nicht ordnungsgemäß an dieses weiter geleitet. Dies führt zu Problemen in den folgenden Bereichen:

Automatisches Resizing
Vererbung von Font-Einstellungen
Fokussteuerung
Verarbeitung von Accelerator Keys

Zur Lösung dieser Probleme müssen die Nachrichten manuell von WindowProxyPanel an AddInSurface weitergeleitet werden. Die folgende Abbildung zeigt die Kommunikation zwischen den beiden Controls:

1. Automatisches Resizing

Das Resizing-Problem ist relativ einfach gelöst. Hierfür muss in WindowProxyPanel lediglich die OnResize()-Methode überschrieben und in ihr die aktuelle Größe über die Win32-Funktion MoveWindow() aktualisiert werden.

protected override void OnResize(EventArgs e)
{
    base.OnResize(e);
    if (m_window != null &&
        m_window.Handle != IntPtr.Zero)
    {
        MoveWindow(m_window.Handle, 0, 0,
            this.Width, this.Height, true);
    }
}

2. Vererbung von Font-Einstellungen

In Windows Forms werden Font- Einstellungen automatisch an die entsprechenden Kindelemente vererbt, wenn diese nicht explizit einen Font festlegen. Diese Vererbungslogik muss ebenfalls manuell nachgebaut werden, da die Windows Forms-Infrastruktur ja nichts von unserem Kindfenster weis.

Dies ist jedoch mit einem einfachen SendMessage()-Aufruf erledigt:

SendMessage(m_window.Handle, WM_SETFONT, this.Font.ToHfont().ToInt32(), 0);

Der Aufruf findet sowohl in der SetWindow()-Methode, als auch in der überschriebenen OnFontChanged()-Methode statt, um auch Font-Änderungen zur Laufzeit entsprechend durchzureichen. In der überschriebenen WndProc()-Methode von AddInSurface wird die WM_SETFONT-Message daraufhin abgefangen und der Font entsprechend gesetzt.

3. Fokussteuerung

Eine richtig dicke Nuss hatte ich mit der Fokussteuerung zu knacken. Zwar kann in der entsprechenden AddInSurface-Ableitung die TabIndex-Eigenschaft der enthaltenen Controls gesetzt werden, die Kontrolle hat hierbei jedoch das hostende Fenster. Und da dieses das Control nicht kennt (da es nicht in seiner Controls-Hierarchie auftaucht) werden die entsprechenden Elemente auch nicht bei Fokusänderungen berücksichtigt.

Zur Lösung ist die WndProc()-Methode sowohl in WindowProxyPanel als auch in AddInSurface überschrieben. Über sie kann direkt in die Win32 Message Loop des Fensters eingegriffen werden. Zum Verarbeitung der Tab-Taste wird die Message WM_GETDLGCODE in WindowProxyPanel abgefangen und manuell an AddInSurface weitergeleitet.

protected override void WndProc(ref Message m)
{
    const int WM_GETDLGCODE = 0x87;

    if (m_window != null &&
        m_window.Handle != IntPtr.Zero)
    {
        if (m.Msg == WM_GETDLGCODE)
        {
            SendMessage(
               m_window.Handle, WM_GETDLGCODE,
               m.WParam.ToInt32(),m.LParam.ToInt32());
            return;
        }
    }
    base.WndProc(ref m);
}

Auf Add-In-Seite wird diese Message wiederum in AddInSurface gefangen und an eine Methode zur Fokussteuerung übergeben:

protected override void WndProc(ref Message m)
{
    const int WM_GETDLGCODE = 0x87;
    const int VK_TAB = 0x09;

    if (m.Msg == WM_GETDLGCODE)
    {
        if (GetAsyncKeyState(VK_TAB) != 0)
        {
            this.TabInto(
               Control.ModifierKeys != Keys.Shift);
        }
    }

    base.WndProc(ref m);
}

Über die Win32-Funktion GetAsyncKeyState() wird hierbei geprüft, ob die Tab-Taste gedrückt wurde. Ist dies der Fall, wird die selbst implementierte TabInto()-Methode aufgerufen, welche für die eigentliche Fokussteuerung zuständig ist. Hierbei wird über Control.MofifierKeys abgefragt, ob zusätzlich die Shift-Taste gedrückt wurde, um eine entsprechende Rückwärtsbewegung des Fokus zu veranlassen.

4. Verarbeitung von Accelerator Key

Accelerator Keys werden ja bekanntlich aktiviert, indem die Alt-Taste zusammen mit einem bestimmten Zeichen gedrückt wird. Sie werden beispielsweise in Labels deklariert um dem Benutzer ein schnelles Springen in das zugehörige Control zu ermöglichen. Auch diese Steuerung ist auf Ebene der Form-Klasse implementiert, sodass hier ebenfalls eine manuelle Implementierung nötig ist. Diese ist in AddInSurface zu finden und ist der Fokussteuerung sehr ähnlich. Doch bevor auf das Drücken von Accelerator Keys reagiert werden kann, müssen diese erst einmal ermittelt werden. Hierfür wurde die OnHandleCreated()-Methode überschrieben, die bei der initialen Erstellung des Control aufgerufen wird.

protected override void OnHandleCreated(EventArgs e)
{
base.OnHandleCreated(e);
this.InitializeAcceleratorKeys(this);
}

Hier wird die InitializeAcceleratorKeys()-Methode aufgerufen, in der die enthaltenen Controls Collections rekursiv durchlaufen und nach Accelerator Keys durchsucht werden. Die gefundenen Keys werden daraufhin in einem Dictionary gespeichert, welches später ausgewertet werden kann.

Das Abfangen von gedrückten Accelerator Keys erfolgt wie gesagt sehr ähnlich wie bei der Focus-Steuerung. WindowProxyPanel sendet die WM_GETDLGCODE-Message, welche von AddInSurface abgefangen und verarbeitet wird. Der entsprechende Code sieht hierbei wie folgt aus:

protected override void WndProc(ref Message m)
{
    const int WM_GETDLGCODE = 0x87;

    if (m.Msg == WM_GETDLGCODE)
    {
        if (Control.ModifierKeys == Keys.Alt)
        {
            this.ProcessAcceleratorKeys();
        }
    }

    base.WndProc(ref m);
}

In der ProcessAcceleratorKeys()-Methode wird daraufhin das Dictionary der Accelerator Keys durchlaufen und der Fokus entsprechend gesetzt.

Den Source Code von WindowsFormsAddInProxy können Sie inkl. Demoprojekt hier herunter laden. Für Feedback bin ich stets dankbar.

PS: Wenn Sie mehr über System.AddIn erfahren möchten, schauen Sie auf der diesjährigen BASTA! Spring Edition vorbei. Dort führen Dominick Baier und ich in der Session „.NET-Anwendungen sicher und robust durch Add-ins erweitern“ in das Thema ein.

Windows Forms Support für System.AddIn, Teil 1

2008-01-07T09:29:00.001+01:00

.NET 3.5 führt mit System.AddIn ist ein neues System zur Erstellung von erweiterbaren Anwendungen ein. Dariusz hat die grundlegenden Details bereits hier und hier beschrieben. Das System hat im Moment jedoch einen Haken: Wenn ein Add-In eine grafischen Oberfläche anbietet möchte, muss dieses – ebenso wie die hostende Anwendung – auf WPF basieren. Eine Unterstützung für Windows Forms existiert zurzeit nicht, was verwunderlich ist, da Windows Forms momentan eine deutlich größere Verbreitung hat.

Da ich das System aber gerne jetzt und nicht erst in der nächsten WPF-Anwendung nutzen wollte, habe ich mir ein Herz gefasst und die nötige Windows Forms-Funktionalität selbst implementiert. Doch bevor ich zu den technischen Details komme, zunächst einige Grundlagen zum besseren Verständnis.

System.AddIn-Architektur

Bei System.AddIn kommunizieren Host und Add-Ins durch eine sogenannte Pipeline, die aus Contracts, Views und Adaptern besteht, wie die folgende Abbildung zeigt.

In der Mitte der Pipeline stehen die Contracts, über die Host und Add-Ins miteinander kommunizieren. Darüber hinaus verfügen beide Seiten jeweils über Views und Adapter. Diese dienen der Isolation und ermöglichen eine sichere und Versions-unabhängige Kommunikation.

Die Add-Ins werden in einer separaten AppDomain oder einem separaten Prozess ausgeführt. Die Kommunikation findet hierbei über den IPC-Channel von .NET-Remoting statt.

Das Hauptproblem bei der Übertragung von UI-Elementen besteht nun darin, dass die Klassen im System.Windows.Forms-Namespace nicht serialisierbar sind und somit nicht direkt übertragen werden können. Die leiten zwar von MarshalByRefObject ab, können aber auch nicht per Referenz übertragen werden. Doch wie sonst soll die Kommunikation erfolgen?

Der Windows Forms Support

Der Trick besteht darin, die Windows Forms-Elemente nicht in serialisierter Form über die Leitung zu schicken, sondern lediglich das Handle der Container-Instanz (z.B. eines User Controls). Dieses kann daraufhin vom Host „umgehängt“ werden. Der Contract für die Kommunikation könnte somit wie folgt aussehen:

public interface IWindowProxy
{
IntPtr Handle { get; set; }
}

Analog zur Pipeline-Architektur wird zusätzlich eine abstrakte Basisklasse für die View-Ebene, sowie eine entsprechende Ableitung zur Verwendung in Add-In und Host benötigt. Hierzu dienen die Klassen WindowProxyBase und WindowProxy, welche dieselbe Signatur wie IWindowProxy aufweisen.

Zusätzlich werden Adapter-Klassen für die Add-In- und die Host-Seite benötigt. Hierfür werden die Klassen WindowProxyViewToContractAddInAdapter und WindowProxyViewToContractHostAdapter bereit gestellt.

Da das alles auf den ersten Blick etwas verwirrend wirken kann, soll das folgende Schaubild für die nötige Transparenz sorgen. Es zeigt den Aufbau der WindowFormsAddInProxy.dll, die alle nötigen Klassen enthält und von den jeweiligen Pipeline-Assemblies referenziert wird:

Das Demo-Projekt

Hat man den Aufbau erst einmal verstanden, ist die Verwendung in einem Add-In-Projekt relativ einfach. Zur Veranschaulichung habe ich ein kleines Demoprojekt erstellt, in dem ein sehr einfacher Contract verwendet wird:

[AddInContract]
public interface IAddInContract : IContract
{
IWindowProxy GetSurface();
}

Die GetSurface()-Methode wird vom Host aufgerufen, um die Oberfläche des jeweiligen Add-In zu ermitteln. Sie liefert eine IWindowProxy-Instanz zurück, sprich das Handle eines User Controls.

Analog dazu werden zwei View-Klassen für die Add-In- und die Host-Seite definiert. Für die Add-In-Seite ist dies die Klasse AddInView:

[AddInBase]
public abstract class AddInView
{
public abstract WindowProxyBase GetSurface();
}

Diese definiert ebenfalls die GetSurface()-Methode, gibt jedoch eine WindowProxyBase-Instanz zurück. Auf Host-Seite wird die Methode durch die AddInHostView-Klasse bereit gestellt.

public abstract class AddInHostView
{
public abstract WindowProxyBase GetSurface();
}

Fehlen noch die entsprechenden Adapter-Klassen. Zunächst die AddInViewToContractAdapter-Klasse der Add-In-Seite:

[AddInAdapter]
public class AddInViewToContractAdapter
    : ContractBase, IAddInContract
{
    private AddInView m_view;

    public AddInViewToContractAdapter(AddInView view)
    {
        m_view = view;
    }

    public IWindowProxy GetSurface()
    {
        WindowProxyBase proxy =
          this.m_view.GetSurface();
        return new
          WindowProxyViewToContractAddInAdapter(proxy);
    }
}

Hier kommt die WindowProxyViewToContractAddInAdapter-Klasse aus der WindowsFormsAddInProxy.dll zum Einsatz, um eine IWindowProxy-Implementierung einer bestimmten Version bereit zu stellen.

Analog dazu stellt AddInContractToHostViewAdapter den entsprechenden Adapter für die Host-Seite bereit.

[HostAdapter]
public class AddInContractToHostViewAdapter
    : AddInHostView
{
    private IAddInContract m_contract;
    private ContractHandle m_handle;

    public AddInContractToHostViewAdapter
        (IAddInContract contract)
    {
        m_contract = contract;
        m_handle = new ContractHandle(contract);
    }

    public override WindowProxyBase GetSurface()
    {
        IWindowProxy proxy = m_contract.GetSurface();
        return new
           WindowProxyViewToContractHostAdapter(proxy);
    }
}

Hier kommt die WindowProxyViewToContractHostAdapter-Klasse zum Einsatz, die für die Bereitstellung einer entsprechenden WindowProxyBase-Instanz sorgt.

Add-In erstellen

Nachdem die Infrastruktur steht, kann es an die Implementierung der Add-Ins gehen. Hierfür muss zunächst einmal eine entsprechende Oberfläche bereit gestellt werden. Die WindowsFormsAddInProxy.dll stellt hierfür die Basisklasse AddInSurface bereit. Sie leitet von UserControl ab und enthält die nötige Logik zum Transfer der Oberfläche über die AppDomain-Grenze. Durch die Ableitung von UserControl kann der Entwurf der Oberfläche bequem über den Control Designer erfolgen, ohne das irgendwelche Add-In-spezifischen Details berücksichtigt werden müssen. Im Demoprojekt habe ich einfach eine Handvoll Controls aus der Toolbox gezogen auf der Oberfläche platziert:

Nachdem die Entwurfsphase abgeschlossen ist, kann es an die Implementierung gehen. Da diese im Wesentlichen nur aus der GetSurface()-Methode besteht, ist das Ganze recht überschaubar:

[System.AddIn.AddIn("Add-In 1",
    Version="1.0.0.0",
    Description="Add-In Nr. 1",
    Publisher="Jörg Neumann")]
public class FirstAddIn : AddInView
{
    private Surface m_surface;

    public override WindowProxyBase GetSurface()
    {
        m_surface = new Surface();
        return new WindowProxy(m_surface);
    }
}

In GetSurface() wird eine Instanz von Surface erzeugt. Surface leitet wiederum von AddInSurface ab und enthält die gerade entworfene Oberfläche. Hierbei ist zu beachten, dass die entsprechende Variable auf Klassenebene deklariert wird, da sonst der Garbage Collector zuschlägt und die Oberfläche nach kurzer Zeit entsorgt. Für die Rückgabe muss nun noch eine WindowProxyBase-Instanz erstellt werden. Dies ist jedoch mit einem Einzeiler erledigt, da WindowProxy ein AddInSurface-Objekt im Konstruktor entgegen nimmt.

Add-In im Host laden

Zum Einbinden der Add-In-Oberfläche in die Host-Anwendung stellt die WindowsFormsAddInProxy.dll die Komponente WindowProxyPanel bereit. Sie leitet von UserControl ab und kann somit direkt auf die Form der Anwendung gezogen werden. WindowProxyPanel hostet die über AddInSurface bereitgestellte Oberfläche und kümmert sich hinter den Kulissen um die Synchronisation der entsprechenden Windows Messages (näheres dazu im nächsten Teil).

Wie die folgende Abbildung zeigt, ist die Oberfläche der Demoanwendung relativ überschaubar.

Sie besteht lediglich aus einer WindowProxyPanel-Instanz, sowie einem Button zur Aktivierung. Der Code zum Laden des Add-Ins liegt der Einfachheit halber direkt im Click-Event Handler:

private void bindAddInButton_Click(
    object sender, EventArgs e)
{
    Collection<AddInToken> availableAddIns =
        AddInStore.FindAddIns(
            typeof(AddInHostView),
            Environment.CurrentDirectory);
    if (availableAddIns.Count > 0)
    {
        instance =
            availableAddIns[0].Activate<AddInHostView>
            (AddInSecurityLevel.Host);
        if (instance != null)
        {
            WindowProxyBase window =
                instance.GetSurface();
            if (window != null)
            {
                this.windowsProxyPanel1.
                    SetWindow(window);
              this.windowsProxyPanel1.Select();
            }
        }
    }
}

Hier werden zunächst über die FindAddIns()-Methode die verfügbaren Add-Ins ermittelt. Daraufhin wird das erste gefundene Add-In über die Activate()-Methode aktiviert, wobei über den Wert AddInSecurityLevel.Host festgelegt wird, dass das Add-In im Sicherheitskontext der Anwendung laufen soll.

Nun kommen wir zum spannenden Teil: Auf der erzeugten Instanz wird über die GetSurface()-Methode die Oberfläche des Add-In ermittelt. Das zurückgegebene WindowProxyBase-Objekt wird daraufhin an das WindowProxyPanel gebunden. Hierzu nimmt dessen SetWindow()-Methode die entsprechende WindowProxyBase-Instanz entgegen.

Im Vergleich zum getriebenen Aufwand sieht das Ergebnis dann doch relativ unspektakulär aus:

Bei dieser Art der Verwendung gibt es jedoch noch einen kleinen Schönheitsfehler. Da die Oberfläche über die Windows API „umgehängt“ wurde, hat Windows Forms keine Informationen über die enthaltenen Controls in der Add-In-Oberfläche. Dies führt dazu, dass bei einem Tab-Wechsel der Fokus lediglich zwischen Button und WindowProxy wechselt und dabei die eingebetteten Controls ignoriert. Zwar wurde eine entsprechende Fokussteuerung in AddInSurface implementiert, diese wird jedoch vom Hostfenster übersteuert. Als Workaround kann die ProcessTabKey()-Methode der Form wie folgt überschrieben werden.

protected override bool ProcessTabKey(bool forward)
{
    if (this.ActiveControl == this.windowsProxyPanel1)
    {
        this.windowsProxyPanel1.TabInto();
        return false;
    }
    return base.ProcessTabKey(forward);
}

Hier wird geprüft, ob die WindowProxyPanel-Instanz gerade aktiviert ist. Wenn ja, wird dieser die Tab-Steuerung durch einen Aufruf der TabInto()-Methode übergeben.

In der Praxis erweist sich dieser kleine Schönheitsfehler jedoch als eher unbedeutend, da das Hauptfenster einer komplexen Anwendung meist aus Menüs, Toolboxen und List Bars besteht und diese nicht über die klassische Tab-Steuerung erreichbar sind.

Im nächsten Teil gehe ich näher auf die Implementierung der WindowsFormsAddInProxy.dll ein und zeige wie die Win32-Kommunikation zwischen Add-In und Host funktioniert.

Den Source Code von WindowsFormsAddInProxy können Sie inkl. Demoprojekt hier herunter laden. Für Feedback bin ich stets dankbar.

Artikel in der aktuellen dotnetpro

2007-10-22T08:23:00.000+02:00

In der aktuellen Ausgabe der dotnetpro (11/2007) ist der Artikel "Einfacher synchronisieren - Die ADO.NET Synchronization Services" erschienen, den ich zusammen mit meinem Kollegen Matthias Hönig geschrieben habe.

Aus dem Abstract:
Bei Offlineclients ergeben sich die meisten Probleme während der Synchronisation der Daten. Genau für diesen Fall hat Microsoft die ADO.NET Synchronization Services entwickelt. Sie werden fester Bestandteil des kommenden .NET Framework 3.5 sein. dotnetpro stellt das System vor.

Slides und Samples von der BASTA!

2007-09-24T11:20:00.000+02:00

Auch diesmal war die BASTA! wieder ein echtes Highlight! Die Slides und Samples meiner Sessions finden Sie hier:

Artikel in der aktuellen dotnetpro

2007-09-24T11:00:00.000+02:00

In der aktuellen dotnetpro (10/2007) ist mein Artikel "Rich Client im Browser – Browseranwendungen mit WPF entwickeln" erschienen.

Aus dem Abstract:
Mit WPF lassen sich nicht nur Desktopanwendungen erstellen. WPF-Applikationen können auch im Browser ablaufen. Dafür stehen gleich fünf verschiedene Technologien zur Verfügung: WPF-Desktop, WPF-ClickeOnce, XAML Browser Application, Loose XAML und Silverlight. dotnetpro stellt die neuen Konzepte vor und zeigt, wie Sie auch ohne HTML beeindruckende Browseranwendungen erstellen.

Artikel in der aktuellen dotnetpro

2007-08-08T14:05:00.000+02:00

In der aktuellen Ausgabe der dotnetpro (9/2007) ist der Artikel "Leicht verfügbar - Ressourcen nutzen mit Windows Presentation Foundation" erschienen, den ich zusammen mit Björn Grossmann geschrieben habe.

Aus dem Abstract:
Mit WPF greifen Entwickler sehr flexibel auf jegliche Arten von Ressourcen zu. Ressourcen können in eine Assembly eingebettet sein oder als lose Dateien im lokalen Dateisystem, in einem Netzwerk-Share oder im Internet vorliegen. Resource Dictionaries ermöglichen die mehrfache Wiederverwendung. dotnetpro stellt die neuen Konzepte vor.

Interessierte finden den Artikel auch als frei verfügbare PDF-Version unter http://dotnetpro.de/articles/freearticles/pdf/2007-09-WPF.pdf

Artikel in der aktuellen dotnetpro

2007-07-19T16:41:00.000+02:00

In der aktuellen dotnetpro (8/2007) sind zwei Artikel von mir erschienen:

Ein zweiter Blick auf Microsoft Silverlight
Ende April fand Microsofts alljährliche Webentwicklerkonferenz MIX statt. Einen der Schwerpunkte bildete die Webtechnologie Silverlight (vormals WPF/E). Sie bietet umfangreiche Multimediafähigkeiten sowie Unabhängigkeit von Plattform und Browser. Außerdem arbeitet sie mit mehreren Programmier- und Skriptsprachen zusammen und bringt eine abgespeckte .NET-Version mit. dotnetpro zeigt, was sich bisher getan hat und beleuchtet bereits geplante Erweiterungen.

Interoperabilität zwischen WPF und Windows Forms
WPF eröffnet eine schöne neue Welt, bricht jedoch mit herkömmlichen Technologien. Eine Anwendung auf WPF umzustellen erfordert mehr, als nur einen Upgrade-Wizard zu starten. Zudem bietet WPF zurzeit noch nicht alles, was bei Windows Forms zum Standard gehört. Der Ausweg: WPF enthält Funktionen, die es ermöglichen, sowohl Windows Forms und ActiveX-Elemente zu nutzen als auch Teile von WPF in klassischen Anwendungen zu verwenden. dotnetpro stellt diese Fähigkeiten vor.

Überarbeitete Auflage des SQL Server 2005 Buchs

2007-07-03T17:39:00.001+02:00

Seit Ende Juni ist die zweite, überarbeitete Ausgabe von "Das Programmierhandbuch SQL Server 2005" verfügbar, dass ich zusammen mit Dirk Mertins und Andreas Kühnel geschrieben habe. Die Seitenzahl ist von 879 auf 1010 Seiten gestiegen und besonders der ADO.NET-Teil ist deutlich erweitert worden.

Artikel in der aktuellen dotnetpro

2007-07-03T09:48:00.000+02:00

In der aktuellen dotnetpro (7/2007) ist mein Artikel "Ressourcenschonender Umgang mit sehr großen Dateien" erschienen.

Aus dem Abstract:
Der Umgang mit Dateien gehört zum Handwerkszeug eines jeden Entwicklers. Das .NET Framework bietet hierfür eine Vielzahl an Klassen. Schwierig wird es jedoch, wenn die Dateien eine bestimmte Größe überschreiten. Dann dauert der Zugriff nicht nur quälend lange, sondern führt auch nicht selten zu einem Speicherüberlauf. dotnetpro zeigt, wie Sie solche Riesendateien effizient verarbeiten und bringt Komponenten und Tools für den praktischen Einsatz gleich mit.

Artikel in der aktuellen dotnetpro

2007-04-16T14:50:00.000+02:00

Für die aktuelle dotnetpro (5/2007) habe ich die folgenden zwei Artikel geschrieben.

Am Puls der Anwendung: Diagnose-Frameworks für .NET 2.0
(zusammen mit Daniel Leinius)
Die Instrumentierung einer Anwendung ist keine leichte Aufgabe. Neben dem eigentlichen Trace-Code müssen Sie sich Gedanken über die anzusprechenden Ausgabeziele, wie EventLog, Datenbank oder WMI Gedanken machen. Diagnose-Frameworks abstrahieren diese Details und nehmen Ihnen die Implementierungsarbeit ab. Vor allem bieten Sie aber ein einheitliches Programmiermodell und eine dynamische Konfiguration zur Laufzeit. dotnetpro stellt drei gängige Frameworks vor, hebt Stärken und Schwächen hervor und gibt Empfehlungen für den Einsatz.

EKG für die Anwendung: Laufzeitanalyse mit .NET 2.0
Die Fehlersuche gehört zu den am wenigsten geliebten Tätigkeiten im Software-Entwicklungsprozess. Erst recht, wenn auf dem Entwicklungsrechner alles funktioniert und Probleme nur im Produktionssystem auftreten. Hier sind aussagekräftige Laufzeitinformationen gefragt. Das .NET-Framework bietet jedoch mit Tracing, Performance Countern und WMI eine Reihe von Technologien, die Ihnen bei der Analyse helfen können. dotnetpro beschreibt die grundlegenden Konzepte und bietet Ihnen Komponenten, die Sie bei Instrumentierung und Überwachung Ihrer Anwendung unterstützen.

Artikel in der aktuellen dotnetpro

2007-03-08T07:33:00.000+01:00

In der aktuellen dotnetpro (4/2007) ist mein Artikel "Wild und wunderbar: Browseroberflächen mit WPF/E entwickeln" erschienen.

Aus dem Abstract:
Mit WPF/E (Windows Presentation Foundation Everywhere) bringt Microsoft eine abgespeckte WPF-Variante, die Web-Sites um Grafik- und Multimedia-Fähigkeiten erweitert und auf verschiedenen Betriebssystemen und Browsern läuft. Da es sich nahtlos in klassische HTML-Seiten integriert, können Sites sehr leicht um interaktiven Videos, Musik oder 2D-Animationen erweitert werden. Die aktuelle CTP (Community Technologie Preview) lässt bereits erahnen, welche Kraft in dieser Runtime steckt. dotnetpro erklärt die Konzepte hinter WPF/E und zeigt, in welche Szenarien der Einsatz sinnvoll ist.

Artikel in der Computer World Schweiz

2007-03-07T09:10:00.000+01:00

In der Ausgabe 50/06 der Computer World Schweiz ist der Artikel "Leichtgewichtige Transaktionen" erschienen, den ich zusammen mit meinem Kollegen Markus Jahn geschrieben habe.

Aus dem Abstract:
Mit .NET 2.0 führt Microsoft ein leichtgewichtiges Transaktionssystem ein, dass nicht nur durch seine gute Performance, sondern vor allem durch seine Einfachheit besticht. Hiervon profitieren insbesondere Datenbankanwendungen, da die entsprechenden ADO.NET-Klassen nahtlos mit dem neuen System zusammen arbeiten. Zudem wird es erstmals möglich, eigene transaktionale Klassen zu erstellen, ohne die Enterprise Services und das dahinter liegende COM+-System verwenden zu müssen.

Slides und Samples von der BASTA!

2007-03-02T14:34:00.000+01:00

Die Spring Edition der BASTA! war auch diesmal wieder ein echtes Highlight. Die Slides und Samples meiner Vorträge finden Sie hier:

Pimp my ElementHost!

2007-02-01T14:37:00.000+01:00

Mit dem ElementHost kann man ja bekanntlich WPF-Content in Windows Forms hosten. Dies geht im Moment jedoch rein programmatisch - eine Windows Forms Designer-Integration existiert (zumindest auf den ersten Blick) nicht.

ElementHost ist von Control abgeleitet und lässt sich somit auf eine Form ziehen (nachdem man die Komponente zuvor in die Toolbox eingefügt hat). Das Erscheinungsbild ist jedoch zunächst äußerst ernüchternd:

Das Control erscheint nämlich nur im Component Tray. Für den Entwurf einer komplexen Oberfläche, die neben Windows Forms auch WPF-Controls enthalten soll, ist das jedoch nicht wirklich akzeptabel.

Ein Blick unter die Haube fördert jedoch zu Tage, dass dies nicht unbedingt eine Limitation des Controls ist, sondern vielmehr auf das Fehlen einer Designer-Assembly zurückzuführen ist. Ein Blick in die WindowsFormsIntegration.dll schafft Klarheit:

[..., Designer("WindowsFormsIntegration.Design.ElementHostDesigner, WindowsFormsIntegration.Design, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")]
public class ElementHost : Control
{
...
}

Demnach wird die Klasse ElementHostDesigner für die Entwurfszeitdarstellung verwendet. Das Problem ist nur, dass die zugehörige Assembly WindowsFormsIntegration.Design.dll nicht zum Lieferumfang von .NET 3.0 gehört. Da die hier angegebene Klasse somit nicht erstellt werden kann, verweigert der Windows Forms-Designer die Darstellung und verbannt die Komponente in den Tray.

Diesen Misstand können Sie jedoch sehr leicht durch eine Ableitung beheben:

[Designer("System.Windows.Forms.Design.ControlDesigner, System.Design, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")]
public class ElementHostControl : System.Windows.Forms.Integration.ElementHost
{
...
}

Hierbei weisen Sie der Klasse über das Designer-Attribut einfach den im Framework enthaltenen ControlDesigner zu. Zur Integration des WPF-Contents verwenden Sie nun statt ElementHost das ElementHostControl.

Damit nun aber zur Entwurfszeit auch der zu hostende Content angezeigt wird, haben Sie zwei Möglichkeiten. Entweder Sie leiten von ElementHostControl ab und erstellen im Konstruktor den Visual Tree programmatisch oder Sie binden ein WPF-Control dynamisch. Hierzu könnten Sie der Klasse z.B. eine ControlType-Eigenschaft verpassen und in dessen Setter die angegebene Klasse per Reflection instanziieren. Das so erstellte Objekt weisen Sie schließlich der Child-Eigenschaft von ElementHost zu.

In der aktuellen Orcas CTP (wohlgemerkt die CTP von VS9 und nicht die WPF-Extensions für VS2005) existiert hingegen die ominöse WindowsFormsIntegration.Design.dll und liefert auch eine sehr nette Integration:

Hierbei ist es auch möglich, das entsprechende WPF-Control innerhalb des WinForms-Projekts zu erstellen, was zurzeit ebenfalls nicht funktioniert.

Scheinbar möchte sich MS wohl noch ein paar Features für Oracas aufheben. Für alle, die zurzeit mit VS2005 + WPF-Extensions arbeiten, bleibt leider nur der oben genannte Workaround.

Neue Tools für WPF und WPF/E

2007-01-05T07:51:00.000+01:00

Lester hat mit XamlPadX v2 ein erweitertes XAML Pad gebaut, dass einige nette Features bietet.
Dominick hat mich auf StyleSnooper aufmerksam gemacht, welches die Styles sämtlicher in WPF enthaltener Controls anzeigt.
Aber wirklich cool ist WPF/E Pad von Mike Harsh. Mehr Infos hier und hier.

Kaxaml rockt!

2006-12-19T15:55:00.000+01:00

Robby Ingebretsen hat mit Kaxaml einen wirklich guten XAML-Editor gebaut. Die aktuelle Version 0.2 enthält Features wie Auto tag completion, XAML Snippets, einen Color Picker, Find & Replace, sowie eine Undo-Funktion. Ein Muß für jeden XAML Pad-Benutzer!

Nähere Infos hier, Download hier.

Artikel in der aktuellen dotnetpro

2006-12-18T15:43:00.000+01:00

In der aktuellen Ausgabe der dotnetpro (01/2007) ist mein Artikel „Neue Klassen, optimierte Verfahren: .NET 2.0: Neuerungen für Komponentenentwickler“ erschienen.

Auszug aus dem Abstract:
Bei der Fülle neuer Features im .NET Framework 2.0 sind einige Neuerungen fast unbemerkt geblieben. Doch gerade im Windows.Forms-Namespace haben sich teilweise tiefgreifende Änderungen vollzogen, von denen insbesondere Komponentenentwickler profitieren können. Jörg Neumann stellt die wichtigsten Änderungen vor und zeigt welche Vorteile die neuen Konzepte haben.

WPF/E: Limitationen bei Event Triggern

2006-12-17T13:38:00.000+01:00

In WPF/E werden zum Animieren von Elementen - ebenso wie in WPF - Event Trigger verwendet. Diese reagieren bei bestimmten Ereignissen und führen daraufhin entsprechende Animationslogik aus.

Die aktuelle CTP unterstützt jedoch nur das Loaded-Event, was die Möglichkeiten deutlich einschränkt. Wenn Sie beispielsweise eine Animation starten wollen, wenn der Benutzer auf ein Element klickt, so können Sie diese zwar per Java Script starten, sie wird jedoch beim initialen Laden der Seite bereits ausgeführt.

Ein Workaround besteht darin, die Animation dynamisch hinzuzfügen. Hierbei deklarieren Sie den Event Trigger nicht in Ihrer XAML-Datei, sondern erzeugen ihn zur Laufzeit per Java Script.

var xaml = "<EventTrigger>";
xaml = xaml + " <EventTrigger.Actions>";
xaml = xaml + " <BeginStoryboard>";
xaml = xaml + " <Storyboard x:Name='imageAnimation'>";
xaml = xaml + " <DoubleAnimation ...";
xaml = xaml + " ...";
xaml = xaml + " </Storyboard>";
xaml = xaml + " </BeginStoryboard>";
xaml = xaml + " </EventTrigger.Actions>";
xaml = xaml + "</EventTrigger>";

var wpfeControl = document.getElementById("wpfeControl1");
var canvas = wpfeControl.findName("rootCanvas");
var trigger = wpfeControl.createFromXaml(xaml);
canvas.Children.Add(trigger);

Bleibt zu hoffen, dass dieser Workaround zur finalen Version überflüssig wird.