Wer eine gewachsene Windows-Desktop-Anwendung von Windows Forms zu WPF migrieren möchte, steht vor einer der häufigsten und lohnendsten Modernisierungsaufgaben in der .NET-Welt. Die Ausgangslage ist dabei fast immer dieselbe: eine Anwendung, die seit Jahren zuverlässig läuft – aber bei jeder neuen Anforderung mehr Widerstand leistet, weil die Architektur nicht für Wachstum gebaut wurde.

Windows Forms existiert seit dem Jahr 2002. Für seine Zeit war es revolutionär – einfach, schnell, produktiv. Heute, mehr als zwei Jahrzehnte später, zeigt die Technologie deutliche Schwächen:

• Keine echte Trennung von UI und Logik – Business-Code, Datenbankzugriffe und UI-Events landen in denselben Klassen. Das Ergebnis: schwer testbarer, eng gekoppelter Code.
• Eingeschränkte UI-Möglichkeiten – Animationen, moderne Controls, adaptive Layouts und High-DPI-Support sind in WinForms entweder unmöglich oder aufwendig zu erkaufen.
• Kein Datenbinding auf Augenhöhe – WPF bietet ein mächtiges, bidirektionales Binding-System. In Windows Forms ist Datenbinding ein nachträglicher Gedanke.
• Technische Schulden häufen sich – Jede neue Anforderung wird teurer, weil die Architektur nicht skaliert.
• Nachwuchsmangel – Entwickler, die neu ins Team kommen, kennen WinForms kaum noch. WPF und MVVM hingegen sind Standard.

Das bedeutet nicht, dass Windows Forms morgen abgekündigt wird – Microsoft pflegt es noch. Aber die Innovationskurve ist flach, und der Abstand zu modernen Technologien wächst täglich.

WPF + MVVM: Was Sie konkret gewinnen

WPF (Windows Presentation Foundation) ist seit .NET 3.0 – also seit 2006 – Microsofts Antwort auf die Schwächen von WinForms. Kombiniert mit dem MVVM-Pattern (Model–View–ViewModel) entsteht eine Architektur, die skaliert, testbar ist und echte Wartbarkeit liefert.

(High-DPI: Seit .NET 6+ hat WinForms Application.SetHighDpiMode() als native Unterstützung.)

Die drei Migrationsstrategien im Überblick

Es gibt nicht einen richtigen Weg. Welche Strategie passt, hängt von Größe, Risikotoleranz und Budget Ihrer Anwendung ab.

Strategie 1: Big Bang – Komplett-Neuentwicklung

Die gesamte Anwendung wird von Grund auf neu in WPF + MVVM entwickelt. Die alte WinForms-Anwendung läuft parallel, bis die neue fertig ist.

Geeignet für: Kleine bis mittelgroße Anwendungen (unter ~20.000 LOC), bei denen der bestehende Code so stark verwachsen ist, dass eine Überarbeitung länger dauern würde als eine Neuentwicklung.

Vorteil: Sauberste Lösung, kein technischer Ballast.
Nachteil: Hohes Risiko, hohe Kosten, lange Zeit ohne produktive Verbesserungen.

Strategie 2: Strangler Fig – Schrittweise Migration

Benannt nach dem Würgefeigenbaum, der langsam den alten Baum ersetzt: Module werden Schritt für Schritt durch WPF-Äquivalente ausgetauscht. Die Anwendung läuft durchgehend produktiv.

Geeignet für: Große Anwendungen (50.000+ LOC), die ständig weiterentwickelt werden müssen. Schrittweise Migration reduziert das Risiko massiv.

Vorteil: Geringes Risiko, kontinuierliche Lieferung, ROI entsteht schon während der Migration.
Nachteil: Längerer Gesamtzeitraum, parallele Pflege beider Technologien nötig.

Strategie 3: Hybrid-Hosting – WPF als Shell um WinForms

WPF übernimmt die äußere Struktur (Navigation, Menü, Fenster-Management), während bestehende WinForms-Controls über WindowsFormsHost eingebettet bleiben und nach und nach ersetzt werden.

Geeignet für: Tight Budget oder sehr komplexe Einzelkomponenten (z.B. proprietäre Steuerelemente), die kurzfristig nicht neu gebaut werden können.

Vorteil: Geringste initiale Kosten, sofort moderner Look.
Nachteil: Technische Schulden bleiben vorerst bestehen, Grenzen der Hybrid-Lösung werden spürbar.

Schritt-für-Schritt: So läuft eine WinForms zu WPF Migration in der Praxis ab

Hier beschreibe ich meinen eigenen Prozess, den ich bei Kundenprojekten anwende – von der ersten Analyse bis zur Übergabe.

Phase 1: Analyse & Bewertung (1–3 Tage)

• Code-Analyse: Wie viele Lines of Code, wie tief ist die Kopplung, gibt es bereits Tests?
• Identifikation der Module und ihrer Abhängigkeiten
• Bewertung: Welche Strategie (Big Bang / Strangler / Hybrid) ist sinnvoll?
• Roadmap und Kostenabschätzung

Phase 2: Architektur-Setup (2–5 Tage)

• Neues WPF-Projekt anlegen (.NET 8 oder .NET 9)
• MVVM-Grundstruktur aufsetzen: ViewModels, Models, Views, Services
• Dependency Injection konfigurieren (z.B. mit Microsoft.Extensions.DependencyInjection)
• Basis-ViewModel mit INotifyPropertyChanged und Command-Implementierungen
• Navigation-Konzept festlegen

Phase 3: Schichtweise Migration

• Business-Logik zuerst – Diese kann oft 1:1 übernommen werden, da sie (im Idealfall) nicht UI-abhängig ist
• Datenzugriffsschicht – Repository-Pattern einführen, Datenbankzugriffe kapseln
• ViewModels – Für jede View ein passendes ViewModel erstellen
• Views (XAML) – Windows Forms-Formulare als XAML-Views neu aufbauen, Bindings setzen

Phase 4: Testing & Review

• Unit-Tests für ViewModels und Services schreiben
• Funktionale Abnahme mit dem Kunden (Verhalten identisch mit altem System?)
• Performance-Check (WPF-Rendering, Memory-Profiling)

Was kostet eine Windows Forms zu WPF Migration?

Eine pauschale Aussage ist hier seriöserweise nicht möglich – aber folgende Orientierungswerte helfen:

Entscheidend für die Kosten sind neben der Codegröße vor allem: Qualität des bestehenden Codes (wie stark ist die Logik in den UI-Events vergraben?), Testabdeckung (gibt es Tests, die Regressions abfangen?) und die fachliche Komplexität (wie viele Sonderfälle gibt es in der Business-Logik?).

Das Strangler Fig Pattern geht auf Martin Fowler zurück – eine ausführliche Erklärung findest du in seinem Original-Artikel auf martinfowler.com.

Die häufigsten Fehler bei der Migration – und wie man sie vermeidet

In meiner Praxis sehe ich immer wieder dieselben Stolperfallen – besonders bei Teams, die WPF zum ersten Mal einsetzen. Das folgende Beispiel zeigt einen typischen WinForms-Code aus einem echten Legacy-Projekt und das WPF-MVVM-Äquivalent nach der Modernisierung:

Was im Vorher-Code konkret schiefläuft

1. SQL Injection – Benutzereingaben werden direkt in SQL-Strings konkateniert ("SELECT * FROM Kunden WHERE id = " + textBox1.Text). Ein Angreifer kann damit die gesamte Datenbank auslesen, manipulieren oder löschen. Je nach firmeninternen Netzwerk-Aufbau häufig eher eine Schnittstelle zur Datenbank sinnvoller, da sicherer.
   
2. Passwort im Klartext – Der Datenbankzugang inklusive Passwort steht direkt im Source Code (Password=1234;). Landet dieser Code in einem Repository, ist die Datenbank kompromittiert. Wird die Anwendung dekompiliert – gleiches Problem.
   
3. Alles in einer Klasse – Form1 enthält gleichzeitig UI-Logik, Datenbankzugriffe und Geschäftslogik. Kein Teil davon ist isoliert testbar oder wiederverwendbar.
   
4. Leeres catch {} – Fehler beim Speichern werden vollständig verschluckt. Die Anwendung tut so, als wäre alles gut – der Nutzer merkt nicht, dass seine Daten nicht gespeichert wurden.
   
5. Kein async/await – Jeder Datenbankaufruf blockiert den UI-Thread. Die Anwendung friert ein, solange die Abfrage läuft.
   
6. Hardcodierte Pfade – C:\\bilder\\aktiv.png funktioniert ausschließlich auf dem Rechner des ursprünglichen Entwicklers.
   
7. Nichtssagende Namen – button1, label5, textBox2 – kein Entwickler versteht ohne Laufzeit, was diese Controls bedeuten.
   
8. Kein Connection-Management – SqlConnection und SqlDataReader werden nicht in using-Blöcken verwendet. Bei einer Exception bleiben Datenbankverbindungen offen.
   

Weitere gängige Fehler / Probleme

1. Code-Behind-Sucht – Der größte Fehler: Logik aus den WinForms-Events einfach 1:1 in den WPF Code-Behind kopieren. Dann haben Sie WPF-Code, der wie WinForms aussieht – und keinen der Vorteile.
   
   Lösung: Konsequent MVVM, Commands statt Click-Events.
   
2. Kein sauberes Binding – x:Name und direkter Code-Behind-Zugriff auf Controls statt Datenbinding.
   
   Lösung: Jede UI-Interaktion läuft über Bindings und Commands.
   
3. Alles auf einmal migrieren wollen – Ohne klare Phaseneinteilung wird das Projekt unüberschaubar.
   
   Lösung: Modulweise vorgehen, lieferfähige Zwischenstände einplanen.
   
4. Dispatcher-Probleme ignorieren – WPF ist threading-sensitiv. UI-Updates aus Hintergrund-Threads ohne Dispatcher führen zu Crashes.
   
   Lösung: Von Anfang an asynchrone Patterns (async/await) und korrekte Dispatcher-Aufrufe implementieren.
   
5. XAML-Performance vernachlässigen – Zu tiefe Visual Trees, fehlende Virtualisierung in Listen, zu viele Converter-Chains.
   
   Lösung: VirtualizingStackPanel für Listen, regelmäßiges Performance-Profiling.

Das Nachher-Bild zeigt dasselbe fachliche Verhalten – aber in einem KundeViewModel mit sauberer Dependency Injection, async/await durchgängig, benannten Properties statt anonymer Controls, und ohne eine einzige Datenbankzeile im ViewModel selbst.

Das ViewModel delegiert nur, funktioniert als „vernetzende Schicht“. Natürlich könnten weitere Anregungen, wie z. B. MediatR, dem CommunityToolkit, etc. eingefügt werden, dies lasse ich aber erstmal bewusst weg 😉.

Planung mit Event Storming: Warum Domänenwissen vor der ersten Codezeile entscheidet

Einer der häufigsten Gründe, warum Migrationsprojekte länger dauern als geplant oder teurer werden als kalkuliert, hat nichts mit Technologie zu tun. Er liegt früher: im fehlenden gemeinsamen Verständnis darüber, was das System eigentlich tun soll – und wer welche Rolle dabei spielt.

In meinen Projekten setze ich deshalb bewusst auf Event Storming als Planungsmethode, bevor eine einzige Zeile neuer Code geschrieben wird. Event Storming ist ein kollaborativer Workshop-Ansatz aus dem Domain-Driven Design (DDD), bei dem Entwickler und Fachexperten gemeinsam die Prozesse eines Systems visualisieren – mit Klebezetteln, klar definierten Ereignissen und expliziten Rollen. Das Ergebnis: ein gemeinsames Bild davon, wer im System was tut, wer was darf, und wo die echten Schmerzpunkte und Hotspots liegen.

Gerade bei Legacy-Anwendungen, die über Jahre gewachsen sind, steckt enormes implizites Wissen in den Köpfen der Anwender – aber nirgends im Code. Event Storming holt dieses Wissen heraus und macht es greifbar. Aus einem solchen Workshop entstehen klare Domänen-Grenzen: Welche Module gehören zusammen? Wo überschneiden sich Verantwortlichkeiten? Welche Teile der alten Anwendung wurden „missbraucht“, weil die eigentlich vorgesehene Lösung fehlte?

Die „Common Language“: Unterschätzt, aber projektentscheidend

Ein Thema, das in der Theorie simpel klingt, aber in der Praxis regelmäßig Probleme verursacht, ist die gemeinsame Sprache – in DDD-Terminologie die Ubiquitous Language. Alle Beteiligten – Auftraggeber, Fachanwender, Entwickler – müssen dieselben Begriffe mit derselben Bedeutung verwenden. Klingt selbstverständlich. Ist es nicht.

Ein konkretes Beispiel aus meiner eigenen Praxis: Ich hatte einen Kunden, der während der Planungsphase abwechselnd von einem „Plugin“ und einer „Extension“ sprach. Ich hörte beide Begriffe, ordnete sie aus Entwicklersicht selbstverständlich als Synonyme ein – und arbeitete entsprechend. Erst im Event-Storming-Workshop stellte sich heraus: Der Kunde meinte mit Plugin und Extension zwei völlig verschiedene Konzepte mit unterschiedlichen Verantwortlichkeiten, unterschiedlichen Lebenszyklen und unterschiedlichen Benutzergruppen. Ohne diesen Workshop wäre die Fehlentwicklung erst Wochen später – und nach vielen Stunden unnötiger Arbeit – aufgefallen.

Genau solche Missverständnisse sind in Legacy-Projekten besonders gefährlich, weil der alte Code die falsche Terminologie oft bereits zementiert hat. Eine saubere Migrations-Planung definiert deshalb frühzeitig ein Glossar: Jeder Begriff, der im Projekt verwendet wird, bekommt exakt eine Bedeutung – schriftlich festgehalten, für alle sichtbar, für alle verbindlich.

Praxisbeispiel: Software für Strafverfolgungsbehörden

Dass dieser strukturierte Ansatz in der Praxis funktioniert, zeigt ein Projekt, das seit 2023 zu meinen prägendsten Erfahrungen zählt: Ein Strafverfolgungsbeamter wandte sich an mich mit dem Wunsch, interne Arbeitswerkzeuge softwaretechnisch zu verbessern. Was folgte, waren sechs verschiedene Softwarelösungen, die ich gemeinsam mit ihm entwickelt und modernisiert habe.

Der Ausgangszustand war typisch für gewachsene Fachanwendungen: sogenannte God-Files – einzelne Klassen oder Dateien mit tausenden Zeilen Code, die alles auf einmal taten – kombiniert mit classic WinForms-Code, bei dem Datenbankzugriffe, Geschäftslogik und UI-Events untrennbar vermischt waren. Das Ergebnis war Code, den man nicht lesen, nicht testen und kaum erweitern konnte.

Nach der Modernisierung: saubere, wartbare WPF-MVVM-Architekturen mit klarer Schichtentrennung, automatisierten Tests und Code, der sich – wie ich es meinen Kunden beschreibe – wie ein Buch liest: von oben nach unten, linear, ohne Überraschungen. Jede Methode tut genau eine Sache. Jede Klasse hat genau eine Verantwortlichkeit. Neue Anforderungen lassen sich einfügen, ohne die bestehende Funktionalität zu gefährden. Dass dieser Anspruch an Code-Qualität in einem sicherheitskritischen Umfeld besonders zählt, versteht sich dabei von selbst.

NuGet-Pakete als Qualitätsbeweis: 60.000+ Downloads

Clean Code und wartbare Architektur sind keine leeren Versprechen – sie lassen sich an öffentlich zugänglichen Ergebnissen messen. Neben Kundenprojekten veröffentliche ich aktiv Bibliotheken auf NuGet, dem zentralen Paket-Repository für .NET-Entwickler. Meine Pakete – darunter rskibbe.I18n für Internationalisierung und rskibbe.Ini für die Arbeit mit INI-Konfigurationsdateien – haben inzwischen über 60.000 Downloads durch andere Entwickler weltweit gesammelt.

Der Ursprung dieser Pakete ist dabei typisch für Probleme, die ich in der Praxis immer wieder antreffe: In zahlreichen Projekten habe ich selbstgebastelten Übersetzungs-Code und selbstgestrickte INI-Parser vorgefunden – jedes Mal neu erfunden, jedes Mal leicht anders, jedes Mal mit denselben Schwächen. Kein einheitliches Verhalten, keine Tests, keine Dokumentation. Ein klassisches Symptom fehlender Wiederverwendbarkeit.

Mir war an einer funktionalen, zentralisierten Lösung gelegen – etwas, das einmal sauber gebaut wird und dann projekt­übergreifend verlässlich funktioniert, ohne dass man dasselbe Problem immer wieder von vorne lösen muss. Genau das habe ich mit rskibbe.I18n und rskibbe.Ini geschaffen: durchdachte, testbare Bibliotheken, die das jeweilige Problem ein für alle Mal lösen – und die andere Entwickler seither in tausenden eigener Projekte einsetzen.

Wer Pakete veröffentlicht, die andere Entwickler freiwillig in ihre eigenen Projekte einbinden, muss liefern: sauberes API-Design, verlässliches Verhalten, gute Dokumentation. Es ist gewissermaßen die härteste Form der Qualitätsprüfung – durch tausende unabhängige Nutzer. Für Sie als Kunde bedeutet das: Die Qualitätsmaßstäbe, die ich an meine eigenen Pakete anlege, gelten genauso für Ihren Code.

FAQ: Häufige Fragen zur Windows Forms zu WPF Migration

Fazit: Lohnt sich die Migration zu WPF?

In nahezu allen Fällen: Ja. Nicht weil WPF die einzige moderne Option ist – aber weil es für echte Windows-Desktop-Anwendungen mit .NET der beste Kompromiss aus Reife, Ökosystem und Zukunftssicherheit bleibt.

Was sich ändert, nachdem eine Migration abgeschlossen ist:

• Neue Features lassen sich deutlich schneller implementieren
• Entwickler finden sich im Code zurecht – auch wenn sie neu ins Projekt kommen
• Unit-Tests werden erstmals möglich, was Regressions reduziert
• Die Anwendung ist wartbar, die technischen Schulden sind abgebaut

Der richtige Zeitpunkt ist jetzt – bevor die Anwendung noch weiter wächst und die Migrations-Kosten steigen.

Der Beitrag Windows Forms zu WPF migrieren: Der vollständige Guide (2026) erschien zuerst auf Robert Skibbe.

The documentation is still a work in progress. Please understand that I do this for free and in my free time.

The goal – An MVVM friendly implementation for WPF

The goal of rskibbe.UI.Dialogs.Wpf.CommunityToolkit is to provide an implementation basis for WPF MVVM based dialogs using the well-known „CommunityToolkit“.

Installation

Use the NuGet Package Manager of Visual Studio to install the base package (and corresponding sub-packages if wanted/needed). The easiest way to access the Manager, is by clicking the „Extra“ menu tool strip menu item, or by right-clicking your project inside the project explorer. Then click something like „Manage NuGet Packages“. There you should be easily able to search for „rskibbe.UI.Dialogs“ and see all possible packages.

Or you can use the following NuGet Package Manager Console command for the newest version:

Install-Package rskibbe.UI.Dialogs
Install-Package rskibbe.UI.Dialogs.Wpf
Install-Package rskibbe.UI.Dialogs.Wpf.CommunityToolkit

Usage in project

To use this package in your project, you just need to install all mentioned dependencies from above. In general, you can refer to „rskibbe.UI.Dialogs.Wpf“ for setup instructions. The only difference here is the base class your deriving from. Instead of using the „DialogViewModelBase“ from „rskibbe.UI.Dialogs.Wpf“ you will be using the „CtDialogViewModelBase“ so that you are able to use the source generators of the „CommunityToolkit“.

Future plans / Todos

Here are some future plans and potential tasks I hope to tackle in the near future. However, please keep in mind that this project is a passion project done in my free time, so I can’t guarantee if or when these updates will be completed.

• More documentation
• More sub packages

Der Beitrag rskibbe.UI.Dialogs.Wpf.CommunityToolkit – A CommunityToolkit implementation erschien zuerst auf Robert Skibbe.

The documentation is still a work in progress. Please understand that I do this for free and in my free time.

The goal – An MVVM friendly implementation for WPF

The goal of rskibbe.UI.Dialogs.Wpf.CommunityToolkit is to provide an implementation basis for WPF MVVM based dialogs. Keep in mind, that this is an extension package of rskibbe.UI.Dialogs – so you will need this package as well – it’s providing the infrastructure for dialogs, creating a common ground.

Installation

Use the NuGet Package Manager of Visual Studio to install the base package (and corresponding sub-packages if wanted/needed). The easiest way to access the Manager, is by clicking the „Extra“ menu tool strip menu item, or by right-clicking your project inside the project explorer. Then click something like „Manage NuGet Packages“. There you should be easily able to search for „rskibbe.UI.Dialogs“ and see all possible packages.

Or you can use the following NuGet Package Manager Console command for the newest version:

Install-Package rskibbe.UI.Dialogs
Install-Package rskibbe.UI.Dialogs.Wpf

Usage in project

To use this package in your project, you just need to install both mentioned dependencies from above. In the next step, you should register the WpfDialogService during your bootstrapping routine in the DI container. In my example, I’m using the „Autofac“ and „Autofac.Extensions.DependencyInjection“ nuget packages for dependency injection.

DI registration (Usually at app startup / bootstrap process)

        // somewhere before
        var builder = new ContainerBuilder();

        // register different dependencies, for example our DialogService
        builder.Register(c =>
        {
            var lifetimeScope = c.Resolve<ILifetimeScope>();
            var autofacServiceProvider = new AutofacServiceProvider(lifetimeScope);
            var dialogService = DialogServiceBuilder
                .New
                .UseServiceProviderForViewModels(autofacServiceProvider)
                .Build();
            return dialogService;
        })
        .As<IDialogService>()
        .SingleInstance();

        ' somewhere before
        Dim builder = New ContainerBuilder()

        ' register different dependencies, for example our DialogService
        builder.Register(Function(c)
               Dim lifetimeScope = c.Resolve(Of ILifetimeScope)()
               Dim autofacServiceProvider = New AutofacServiceProvider(lifetimeScope)
               Dim dialogService = DialogServiceBuilder _
                   .New _
                   .UseServiceProviderForViewModels(autofacServiceProvider) _
                   .Build()
               Return dialogService
           End Function) _
        .As<IDialogService>() _
        .SingleInstance()

Creating a DialogViewModel implementation

To use the WpfDialogService’s „ShowDialogAsync“ method, it needs an implementation of „IDialogViewModel“. The provided „DialogViewModelBase“ from the „rskibbe.UI.Dialogs.Wpf“-package will help as base class. If your are used to build your WPF MVVM apps using the typical „CommunityToolkit“ package, there’s also support for this, installing „rskibbe.UI.Dialogs.Wpf.CommunityToolkit“ – then you could use the source generators.

In this example, we will create a dialog using the „DialogViewModelBase“ base class. After creating the example ViewModel from below, fill it – as usual – with life (like commands, properties, etc.) and create a corresponding View for it like „MyDialogView“.

// don't forget to import the base class
using rskibbe.UI.Dialogs.Wpf;

public class MyDialogViewModel : DialogViewModelBase
{

   // your DialogViewModel logic
   // create properties to bind from view
   // create commands to bind from view

}

' don't forget to import the base class
Imports rskibbe.UI.Dialogs.Wpf

Public Class MyDialogViewModel
   Inherits DialogViewModelBase

   ' your DialogViewModel logic
   ' create properties to bind from view
   ' create commands to bind from view

End Class

Using the injected DialogService

After like typical constructor dependency injection, you can use the dialog service like the following. You can either use the generic method overload, or you could first resolve a ViewModel for yourself from the dependency injection container.

// don't forget the imports
using rskibbe.UI.Dialogs;

public class YourViewModel
{

  IDialogService _dialogService;

  public YourViewModel(IDialogService dialogService)
  {
      _dialogService = dialogService;
  }

  // should be an ICommand, of course...
  private void Bla()
  {
      bool? dialogResult = _dialogService.ShowDialogAsync<MyDialogViewModel>();
      // do something with the result
  }

}

' don't forget the imports
Imports rskibbe.UI.Dialogs

Public Class YourViewModel

  Private _dialogService As IDialogService

  Sub New(dialogService As IDialogService)
      _dialogService = dialogService;
  End Sub

  ' should be an ICommand, of course...
  Private Sub Bla()
      Dim dialogResult As Boolean? = _dialogService.ShowDialogAsync<MyDialogViewModel>();
      ' do something with the result
  End Sub

End Class

Key takeaways

Here I will talk about the key takeaways of this package, explaining classes, important stuff, the thoughts behind and so on.

IDialogViewModel

The MVVM friendly base-interface for implementing / extending IDialog from the base package.

DialogViewModelBase

A custom ViewModelBase implementation for IDialog / IDialogViewModel (and INotifyPropertyChanged behind the scenes).

WpfDialogServiceBuilder

A helper class to build „WpfDialogServiceBase“ for WPF MVVM apps using „Window“ as dialogs (or based on).

WpfDialogServiceBase

A base class for constructing your own IDialogService implementation.

WpfDialogService

A standard implementation of an IDialogService for typical WPF MVVM apps. (You can use another package called „rskibbe.UI.Dialogs.Wpf.CommunityToolkit“ if you need an implementation supporting the commonly used CommunityToolkit and – for example – its source generators).

Future plans / Todos

Here are some future plans and potential tasks I hope to tackle in the near future. However, please keep in mind that this project is a passion project done in my free time, so I can’t guarantee if or when these updates will be completed.

• More documentation
• More sub packages

Der Beitrag rskibbe.UI.Dialogs.Wpf – An extension package for MVVM dialog implementation in WPF erschien zuerst auf Robert Skibbe.

The documentation is still a work in progress. Please understand that I do this for free and in my free time.

In my daily work as a freelance developer, I encounter a wide range of customer requirements, user stories, and technologies. When it comes to technologies—where we’ll dive deeper in a moment—I’m particularly referring to foundational concepts such as:

• Windows (UI – not the Operating System)
• Modal and non modal dialogs
• Screens (stuff that gets displayed inside the Windows, etc.)
• and more…

I was frustrated by having to repeat the same tasks over and over. It wasn’t the work itself that bothered me, but rather the repetitive, tedious tasks—the „monkey work.“ The kind of work that’s necessary, but always leaves you thinking, „There must be a faster, better way to do this.“

That’s exactly why I created my own little package: „…the UI stuff I always need.“ I decided to make it freely available for everyone, so others can benefit from it and save time on repetitive tasks too.

So, feel free to use it or one of the (soon to follow) sub packages for corresponding technologies like WPF , Winforms, etc.

The goal – A common ground for WPF, Winforms, Consoles & more

The goal of rskibbe.UI.Dialogs is to provide a unified infrastructure package that addresses the fundamental needs across various UI technologies like WPF, Windows Forms (WinForms), and even Console Apps. The aim is to consolidate „what’s commonly required“ into a single, versatile package.

Installation

Use the NuGet Package Manager of Visual Studio to install the base package (and corresponding sub-packages if wanted/needed). The easiest way to access the Manager, is by clicking the „Extra“ menu tool strip menu item, or by right-clicking your project inside the project explorer. Then click something like „Manage NuGet Packages“. There you should be easily able to search for „rskibbe.UI.Dialogs“ and see all possible packages.

Or you can use the following NuGet Package Manager Console command for the newest version:

Install-Package rskibbe.UI.Dialogs

Key takeaways

Here I will talk about the key takeaways of this package, explaining classes, important stuff, the thoughts behind and so on.

DialogState Enum

Represents the different states (lifecycle) of a dialog.

ICloseAsync Interface

Denotes something that can be closed async – the closing process itself could take some time.

IClosedAsync Interface

An interface denoting something which has been closed async – the closing itself has been completely finished and this is the „after state“ before being cleaned up.

IDialog Interface

An internface denoting a typical Dialog implementing „INotifyPropertyChanged“ to propagate state changes. Important: It contains a „DialogResult“, „DialogState“ and „IsBusy“ properties to represent the states / results of a typical dialog.

IDialogService Interface

Denotes something that handles showing dialogs like „ShowDialogAsync“, etc.

IInitializeAsync Interface

Denotes something that can be Initialized async – initialization should be rather quick than slow (still enabled for like loading a quick file, whatever).

IShowAsync Interface

Denotes something that can be shown – put code here, that is executed during the „show“ process itself (like loading a customer from database, showing an indicator meanwhile, etc.).

IShownAsync Interface

Denotes something that can be shown async – put code here, that should be executed, after the „showing“ process of like loading a customer has been completed and should be run afterwards.

Sub packages

Here, you’ll find the freely available sub-packages that complement the main package. These sub-packages are tailored to support specific technology stacks, such as WPF MVVM or Windows Forms (WinForms), helping to establish a solid foundation for developing your applications.

rskibbe.UI.Dialogs.Wpf

One of the sub packages which is responsible for providing the WPF MVVM related infrastructure is: „rskibbe.UI.Dialogs.Wpf„.

rskibbe.UI.Dialogs.Wpf.CommunityToolkit

One of the sub packages which adds easy support for using the well-known „CommunityToolkit“: „rskibbe.UI.Dialogs.Wpf.CommunityToolkit„.

Future plans / Todos

Here are some future plans and potential tasks I hope to tackle in the near future. However, please keep in mind that this project is a passion project done in my free time, so I can’t guarantee if or when these updates will be completed.

• More documentation
• More sub packages

Der Beitrag rskibbe.UI.Dialogs – A base package for dialog infrastructure erschien zuerst auf Robert Skibbe.

This is a sub package for the base NuGet package extending the infrastructure provided by „rskibbe.UI.Screens„. This package is dependent on CommunityToolkit.MVVM package, as it’s the most commonly used one in terms of WPF and MVVM. I decided to not stripe it away, as I think, that this is the absolute core of using MVVM – therefore I’m currently not planning to remove it in the near future.

Currently, this package is also dependent on the Autofac „Dependency Injection Library“ as I’m using it in almost every app I build. I spent some time making it based on the „IServiceProvider“ interface, but as it’s not as powerful, I decided to drop it – especially in terms of my own time. Maybe I’ll change that in the future, but currently, this isn’t planned as well.

Keep these two things in mind, when using the package!

The documentation is still a work in progress. Please understand that I do this for free and in my free time.

Installation

Use the NuGet Package Manager of Visual Studio to install the base package (and corresponding sub-packages if wanted/needed). The easiest way to access the Manager, is by clicking the „Extra“ menu tool strip menu item, or by right-clicking your project inside the project explorer. Then click something like „Manage NuGet Packages“. There you should be easily able to search for „rskibbe.UI.Screens.Wpf“ and see all possible packages.

Or you can use the following NuGet Package Manager Console commands for the newest versions:

Install-Package rskibbe.UI.Screens
Install-Package rskibbe.UI.Screens.Wpf

Key Takeaways

• WpfApp Class
• WpfWindow Class
• ViewModelBase Class
• ScreenViewModelBase Class

WpfApp Class

In general, the „System.Windows.Application“ class is the core of each WPF application. For my use cases I mostly have recurring things I have to do, like:

• Registering Dependencies
• Defining the start window
• Instantiating the starting viewmodel
• Overriding „OnStartup“ method
• etc…

To make these steps easier I created this class which combines / wraps these „every time I start a new WPF app“ steps. Let your own App derive from the WpfApp class and override the abstract methods to kickstart everything.

There are some conventions going on behind the scenes, to avoid overhead, repetitive and annoying duplications:

RegisterViewModels

This method gets called automatically behind the scenes to register the ViewModels of your application. Take a look at it’s description to learn more about finetuning these aspects.

Primarily there are 3 important methods to be overriden:

RegisterAdditionalDependencies

Use this method to like register services, repositories and anything else.

GetMainWindowType

This method should return the type of the MainWindow, as my app can’t know which Window-Class you’re going to use for your individual project. The class needs to have an empty constructor to be instantiated.

GetMainWindowViewModelType

This method should return the type of the MainViewModel class, as my app can’t know which ViewModel class you’re going to use for your individual project.

WpfWindow Class

The WpfWindow class represents the MainWindow of the app. It implements „IWpfWindow“ from above, is therefore having a „CurrentScreen“ implementing „IScreen“. It inherits the typical „System.Windows.Window“ WPF class. In modern app development, it’s usual to have some sort of main window which is just switching between different sub-screens.

Usually, you should use a derived class of the „HostScreenViewModelBase“ if you want that navigation-ish app style, or you could use derived class of the „ScreenViewModelBase“ if you want like a one-screen app.

ViewModelBase Class

Nothing big to be seen here, the „ViewModelBase“ class is just – as it’s suggesting – a base class for any kind of ViewModel. It depends on the „CommunityToolkit.MVVM“ ObservableObject class.

ScreenViewModelBase Class

<more to come>

Future plans / Todos

Here are some future plans and potential tasks I hope to tackle in the near future. However, please keep in mind that this project is a passion project done in my free time, so I can’t guarantee if or when these updates will be completed.

• More documentation
• Getting rid of unnecessary dependencies
• Logging without Debugger (something like Microsoft.Extensions.Logging.ILogger)

Der Beitrag rskibbe.UI.Screens.Wpf – A common ground for WPF MVVM related UI infrastructure erschien zuerst auf Robert Skibbe.

Kennst Du das auch: Du sitzt vor Deinen .NET Klassen und musst für WPF und Co. die INotifyPropertyChanged-Schnittstelle das gefühlte tausendste Mal implementieren? Eigentlich hättest Du Besseres zu tun und der Kunde (oder Dein Chef) sitzt Dir schon im Nacken? Damit ist nun Schluss – also mit dem repetitiven implementieren der Schnittstelle –, denn dafür gibt es Abhilfe!

Installiere dazu einfach die beiden NuGet-Pakete „PropertyChanged.Fody“ und „Fody“. Konfiguriere Diese mit einer passenden „FodyWeavers.xml“-Datei und erstelle eine Klasse, Welche die INotifyPropertyChange-Schnittstelle implementiert, fertig!

Keine Lust auf „Monkey Work“ – Hilfe muss her!

Jeder .NET Entwickler, Welcher mit Daten und dessen Änderungen in Verbindung kommt, kennt es. Man muss der grafischen Oberfläche „Hey, der Vorname hier, der hat sich geändert, bitte zeige Den einmal aktualisiert an!“, mitteilen. Für gewöhnlich passiert das im .NET-Umfeld über die INotifyPropertyChanged-Schnittstelle. Diese kann nicht wirklich viel – wie auch als Interface –, Sie gibt uns jedoch den Schlachtplan für genau diese Frage: „Welche Eigenschaft hat sich geändert?“.

Wie oben schon erwähnt kann es aber nun ziemlich langweilig und vor Allem nervig werden. Schließlich besteht unsere Anwendung für gewöhnlich aus zig Klassen, Welche alle gewisse Daten beinhalten, dessen Änderungen nach außen mitgeteilt werden möchten. Tun wir dies nicht, bekommt die grafische Oberfläche davon nichts mit und kann die aktualisierten Daten auch nicht anzeigen.

Uns bleibt also nichts Anderes übrig, als die Schnittstelle in jeder benötigten Klasse zu implementieren, oder? Zum Glück ist dem nicht so! Wie das funktioniert, erfährst Du im weiteren Verlauf.

Im Videoformat

Möchtest Du etwas auf die Augen und die Ohren bekommen? Ist Dir der Text eventuell zu träge? Dann schaue Dir gerne das passende Video auf meinem YouTube-Kanal an. Beachte, dass das deutsche Video VB.NET als Sprache verwendet, allerdings ist dies natürlich genauso gut auf C# anwendbar. Ich empfehle Dir trotzdem, den Beitrag ebenso anzuschauen, da ich hier nochmal in mehr Detail auf die einzelnen Dinge eingehen kann.

Einfacher, ja, aber „ich dachte da ist mehr drin“

Wenn Du meinen detaillierten Beitrag über die INotifyPropertyChanged-Schnittstelle gelesen / gesehen hast, kennst Du vermutlich schon eine Vereinfachung. Diese haben wir erreicht, indem wir eine mehr oder weniger generischere Variante geschrieben haben. Dort gab es eine gewisse Methode (NotifyOfPropertyChange) innerhalb einer Klasse, Welche den Namen der geänderten Eigenschaft entgegengenommen hat. Das hat uns zumindest das Auslösen des „PropertyChanged“-Ereignisses vereinfacht.

Das Tolle daran war auch, dass wir den Namen der geänderten Eigenschaft nicht manuell angeben mussten. Dies konnte durch das „CallerMemberName“-Attribut des übergebenen Parameters automatisch bestimmt werden – insofern die Methode aus dem Setter der Eigenschaft aufgerufen wurde. Wenn man dann noch den „NameOf“-Ausdruck verwendet, hat man schon eine wirklich solide Basis.

Letztendlich stinkt es einem dennoch, wenn man folgenden Code sieht, Dieser ist einfach nur repetitiv und somit nicht gerade DRY getreu. Ebenso bläht er den Code unnötig auf und man hat fast gar keine Lust mehr, Diesen zu lesen. Das ist natürlich fatal..

 Public Class SomeThing
    Inherits PropertyChangedBase

    Private _company As String

    Public Property Company As String
        Get
            Return _company
        End Get
        Set(value As String)
            If _company = value Then
                Return
            End If
            _company = value
            NotifyOfPropertyChange()
        End Set
    End Property

    ' property 2...

    ' property 3...

    ' ...

End Class

public class SomeThing : PropertyChangedBase
{
    private string _company;

    public string Company
    {
        get => _company;
        set
        {
            if (_company == value)
                return;
            _company = value;
            NotifyOfPropertyChange();
        }
    }

    // property 2...

    // property 3...

    // ...

}

Fody installieren

Das NuGet-Paket des Vertrauens, Welches uns die Arbeit erleichtern wird, nennt sich „Fody“. Also zumindest das Haupt-Paket, zusätzlich brauchen wir ein Sub-Paket namens „PropertyChanged.Fody“. Installiere nun also bitte beide Pakete, indem Du entweder die grafische Oberfläche des NuGet Paket-Managers, oder dessen Konsole verwendest.

Die Entwickler von Fody empfehlen es, die Konsolen-Variante zu verwenden, ich hatte bisher aber ehrlich gesagt noch nie Probleme mit der GUI-Variante. Gehe oben in Visual Studios Menüleiste auf „Extras“ und wähle „NuGet-Paket-Manager“. Dann wählst Du „Paket-Manager-Konsole“, schon sollte sich ebendiese Konsole öffnen.

Kopiere nun die beiden Befehle und führe Sie einzeln in der Paket-Manager-Konsole aus:

Install-Package Fody
Install-Package PropertyChanged.Fody

Fody konfigurieren

Leider sind wir noch nicht fertig, nachdem wir die notwendigen Pakete installiert haben, noch nicht! Wir müssen die installierten Pakete noch konfigurieren. Fody weiß ansonsten nicht, was es tun soll, bzw. Welche Sub-Pakete (es gibt noch mehr..) verwendet werden sollen.

Wir haben für unseren Bedarf ja das „PropertyChanged.Fody“-Sub-Paket installiert, Dieses konfigurieren wir nun als „wir möchten das gerne verwenden“. Lege dazu im nächsten Schritt eine XML-Datei in Deinem Projektverzeichnis an. Klicke dazu einfach mit einem Rechtsklick auf Deine Projektmappe und wähle „Hinzufügen->Neues Element“. Beachte bitte, dass die neuste Version von Visual Studio eine neue Darstellung – die Kompaktansicht – gewählt hat.

Diese Kompaktansicht kannst Du ganz einfach „ausklappen“, indem Du die jeweilige Option unten links anklickst. Erstelle mit Hilfe des Dialoges nun die XML-Datei und betitle Sie als „FodyWeavers.xml„. In diese Datei gibst Du nun folgenden Text, für unser Beispiel ein:

<?xml version="1.0" encoding="utf-8"?>
<Weavers xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="FodyWeavers.xsd">
  <PropertyChanged />
</Weavers>

Ich hatte hier übrigens ursprünglich nur das „Weavers“-Tag und das Kind „PropertyChanged“ eingefügt. Der Rest wurde später automatisch ergänzt (ehrlich gesagt, keine Ahnung woher, vermutlich durch VS oder Fody selbst). Das sah vorher so aus und reichte wohl auch:

<Weavers>
  <PropertyChanged />
</Weavers>

Unsere finale Klasse

Im letzten Schritt reicht es aus, dass Du einfach nur eine Klasse erstellst, Welche die „INotifyPropertyChanged“-Schnittstelle implementiert – das war’s! Dies kann z. B. durch Vererbung der im anderen Beitrag gezeigten „PropertyChangedBase“-Klasse passieren, oder Du machst es manuell. Ebenso stellt Fody ein Klassen-Attribut zur Vereinfachung bereit.

Beispiel 1 – Vererbung (nach wie vor):

Hier verwenden wir die ganz „normale“ Vererbung, mit der Klasse aus dem anderen Beitrag. Der Vorteil hier ist: Falls wir doch eigene Setter o Ä. schreiben, können wir immer noch auf die Hilfs-Methode „NotifyOfPropertyChange“ zugreifen.

 Public Class SomeThing
    Inherits PropertyChangedBase

    Public Property Company As String

    ' property 2...

    ' property 3...

    ' ...

End Class

public class SomeThing : PropertyChangedBase
{

    public string Company { get; set; }

    // property 2...

    // property 3...

    // ...

}

Beispiel 2 – Mit Attribut von Fody & ohne Vererbung

Hier benötigen wir keine zusätzliche Klasse! Durch das Attribut über der Klasse, weiß Fody, dass hier am Ende die INPC-Schnittstelle automatisch implementiert werden soll – nice!

 Imports PropertyChanged

 <AddINotifyPropertyChangedInterface>
 Public Class SomeThing
    Inherits PropertyChangedBase

    Public Property Company As String

    ' property 2...

    ' property 3...

    ' ...

End Class

using PropertyChanged;

[AddINotifyPropertyChangedInterface]
public class SomeThing
{

    public string Company { get; set; }

    // property 2...

    // property 3...

    // ...

}

„PrivateAssets“-Meldung / Warnung

Durch die Verwendung der vorgestellten Vorgehensweise mit Fody, sparen wir uns (wie Du sicherlich gemerkt haben wirst) eine Menge an Aufwand. Leider kommt es hier und dann noch zu einer kleinen Warnung. Diese Warnung sieht in etwa wie folgt aus:

Warnung FodyPackageReference „Fody: The package reference for PropertyChanged.Fody does not contain PrivateAssets=’All'“

In meiner aktuellen Installation für diesen Beitrag und dem zugehörigen Video, hatte ich dieses Problem nicht. Vielleicht nimmt das dem ein oder anderen Tester die Angst vor Neuem – es lohnt sich wirklich.

Was bedeutet die „PrivateAssets“-Warnung?

Bevor wir uns an die Problemlösung wagen, sollten wir vielleicht erstmal verstehen, was die Warnung überhaupt bedeutet. Kurzum ist dieses sogenannte „Metadata-Tag“ (ein Schlüsselwort / Stichwort in den Metadaten) dazu da, um Abhängigkeiten zu steuern.

Ich zitiere dazu einfach mal den Punkt aus der offiziellen Dokumentation, wo Du natürlich gerne reinschauen darfst:

Sie verwenden eine Abhängigkeit möglicherweise rein als Entwicklungsumgebung und möchten diese nicht für Projekte verfügbar machen, die Ihr Paket nutzen. In diesem Szenario können Sie dieses Verhalten über die PrivateAssets-Metadaten steuern.

Kurzum heißt das: Wenn wir nicht möchten, dass unsere verwendeten Helferlein (PropertyChanged.Fody, Fody) nach außen sichtbar sind, verwenden wir dieses Metadaten-Tag. Letztendlich brauchen wir Fody nur zur Entwicklung, daher ist es weniger nach außen relevant.

Wie beheben?

Die Warnung dementsprechend zu beheben ist nicht wirklich schwer, es ist letztendlich nur eine Konfigurationssache. Klicke dazu einfach mit einem Rechtsklick auf Dein Projekt und wähle „Projektdatei bearbeiten„. Danach fügst Du einfach das Tag wie im Bild markiert hinzu – schon sollte die Meldung verschwinden!

Downloads

Keine Lust alles abzutippen und manuell ran zu gehen? Verständlich! Lade Dir einfach das passende Beispielprojekt herunter und starte ohne Verzögerung.

Der Beitrag INotifyPropertyChanged in .NET automatisch implementieren erschien zuerst auf Robert Skibbe.

The WPF ListView – listing items / things

In today’s post, we are going to talk about one of the most basic controls: The WPF ListView. We will take a look at the different use cases of the ListView and we will try out some of the architectural styles. As MVVM is like the „way to go“ in WPF, I will definitely examine this, but we won’t forget the „old way“. Like always, I will provide different source code examples in the two most used .NET languages, being C# and VB.NET.

This guide and all examples are compatible with .NET 8 and .NET 9.

Speaking of languages: Make sure Visual Studio is set up correctly → Change VS Installer Language.

Need quick help? Jump to the corresponding sections by using the table of contents. When you are using the code behind based approach, jump there. If you are more the MVVM guy, you could jump and start with the „MVVM approach“ section.

What is a WPF ListView?

When stumbling upon this control, the first question coming to your mind could be: „Well, what is a ListView – in the Windows Presentation Foundation – in the first place?“. I mean, by the name, you could just assume, that it’s something for displaying like a „list“ of something, right? I mean, you are pretty much on the right side, but what makes it different from like a DataGrid, or even a ListBox? Don’t worry, we will cover this is a few minutes, further down below.

The definition, I guess?

Let’s first define, what a ListView really is by like definition:

A WPF ListView provides the basic tools needed, to help you displaying a set of data items. This can be easily done in like different views or layouts, depending on your usecase. Each item of those ListViews are displayed, using something called ListViewItem. A ListViewItem iteself is – more or less – just another template-ish element, being a ContentControl.

Examining the ListView

Let’s take a quick sneak peek into the inheritance-tree, of the WPF ListView Control, by pressing F12, while being on one of those with your mouse cursor. There you can see, that it actually inherits from the class ListBox.

Inheritance tree

Going further down, there are some other classes in the inheritance tree as well, like the Selector & the ItemsControl class. I think, for most persons, it’s actually a surprise / a „good to know“-thing, that the ListView actually inherits from the ListBox class.

At this point, you can see, that there’s pretty much going on in the background. The ListView itself is actually derived from a few levels of control hierarchy and is therefore bringing a lot „to the table“. For sure, we can’t go to every level in detail, but I think the most important ones for you are beginning at the ItemsControl.

I mean, in a real application scenario, you would most likely fetch some data like the „charts“ or something like that. Those could then be displayed inside your ListView by specifying what should actually appear. The chart object could be composed from many different objects and therefore you would need to specify a bit further.

A first example – with XAML & code behind

Let’s now focus on creating an actual first example of the ListView Control. To do so, we usually need to first have some kind of data to display. At this point, we will just create some hardcoded items, to see, how the ListView and its ListViewItems are created in the first place. Keep in mind, that we will do this and more in an MVVM manner, later – which is the preferred way for me personally.

We will surround the ListView by a GroupBox Control, to have some kind of labelling, etc. So go ahead and create a GroupBox XAML markup inside your MainWindow.xaml (inside the root Grid). You can write something like „Music stars“, etc. inside the Header Property of that GroupBox, like this, we have some kind of heading for our list.

After that, we can add some sort of styling like padding, a width and alignments to that GroupBox, to make it look less bruised. The final, but first testing XAML code could therefore look like this:

    <Grid>
        <GroupBox Header="Some items" Padding="8" Width="200" VerticalAlignment="Center" HorizontalAlignment="Center">
            <ListView>
                <ListView.Items>
                    <ListViewItem Content="Jimmy Hendrix" />
                    <ListViewItem Content="Michael Jackson" />
                    <ListViewItem Content="The Beatles" />
                </ListView.Items>
            </ListView>
        </GroupBox>
    </Grid>

The visual representation of that XAML code from above, will just look as simple as this.

How to add items to the WPF ListView?

To add some items to the ListView in a „code behind“-manner, we need to specify a usual handler for like the click event, of for example a button. We can then react to that click inside of the handler and actually add a new item to the ListView. Go ahead and add a button inside of your MainWindow (Grid) and specify the „Click“-Property.

<Button Click="Button_Click" />

It will suggest, to create an actual handler, you can confirm this and press F12 while being on the „Button_Click“ text. After that, it will automatically jump to the corresponding part in your code – the code behind file. Feel free to rename that handler (in XAML & code) to pick a better name, like „btnAddItem_Click“.

Inside of the click handler, we need to somehow say: „Hey, ListView, please remove an item!“. And we are only able to do so, if we have something to talk to. Currently, the ListView doesn’t have a name, so you should go back and specify a name for it:

<ListView x:Name="MusicArtistList" ....>
    <!-- .... -->
</ListView>

The button click handler itself could just look like the following. We are just telling the property of the „MusicArtistList“, called „Items“: „Hey, please add another entry to yourself, thanks!“.

    private void Button_Click(object sender, RoutedEventArgs e)
    {
        MusicArtistList.Items.Add("Sam Smith");
    }

    Private Sub Button_Click(sender As Object, e As RoutedEventArgs)
        MusicArtistList.Items.Add("Sam Smith")
    End Sub

How to remove items from the ListView again?

If you have followed the above steps to actually add an item inside of our ListView, then you could be ready to remove it again. Keep in mind, that you should have like the click handler ready (by specifying the Buttons click property with like „btnRemove_Click“) and that the ListView needs a name. Otherwise, we wouldn’t be able to target it from the code behind file.

    private void btnRemove_Click(object sender, RoutedEventArgs e)
    {
        // this only works that easy due to our current "strings" example
        MusicArtistList.Items.Remove("Sam Smith");
    }

    Private Sub btnRemove_Click(sender As Object, e As RoutedEventArgs)
        ' this only works that easy due to our current "strings" example
        MusicArtistList.Items.Remove("Sam Smith")
    End Sub

How to delete the selected item in the ListView?

This one here is a bit different, because we can’t know at compile time, which one of the items, the user will select. We can’t therefore hardcode like a specific string thing, to be deleted later. We need a possibility, to get the currently selected item and delete it somehow.

This is actually pretty easy, as we get everything we need to know, from the ListView itself. We will first check, if there’s an actual selection and if so, we will delete that item by providing its index.

    private void btnRemoveSelectedItem_Click(object sender, RoutedEventArgs e)
    {
        bool noItemSelected = MusicArtistList.SelectedIndex == -1;
        if (noItemSelected)
            return;
        MusicArtistList.Items.RemoveAt(MusicArtistList.SelectedIndex);
    }

Private Sub btnRemoveSelectedItem_Click(sender As Object, e As RoutedEventArgs)
    Dim noItemSelected As Boolean = MusicArtistList.SelectedIndex = -1
    If noItemSelected Then
        Return
    End If
    MusicArtistList.Items.RemoveAt(MusicArtistList.SelectedIndex)
End Sub

Okay, but not flexible, nor practical – imo

So in the end, we just created a small ListView representation with like 3 entries for our music stars / artists. Currently, this isn’t really good, as it’s not dynamic or based on „real data“. We just hardcoded those ListViewItems inside the ListView and this isn’t pretty much practical.

The other problem with our current example is, that it’s not pretty flexible, currently we are having only like „1 Column“. With that, we can only display one „thing“ per item and we are not really different from a ListBox. What if we wanted to publish some sort of „year of birth“ information? I mean sure, we could just pump it into one string, but nah, that doesn’t feel right.

What we really need are some sort of columns and guess what, the ListView supports this out of the box, by just specifying the View property.

Working with „real data“ – MVVM approach

Moving away from that unpractical non-databased „stringish“ approach from above, we will now start a newer, clean version of our ListView Control. But first, we need to actually define „what“ to display, I mean, we need some sort of a so called „Model“ (or even a ViewModel – but I’ll leave it at that for now). As we wanted to display some sort of „music star“-overview, we could think of a better term in the first place. I will call it list of artists, so let’s now create a new class called „MusicArtist“ inside a matching folder.

Go ahead and create the corresponding folder inside your WPF project, first. We will call that folder like „Models“ – remember, I don’t want to go too deep into the MVVM cosmos. I would encourage you to refer to my C# MVVM post for that and don’t be confused, it will for work VB.NET as well. I mean the characteristics of Model-View-ViewModel are in the focus, not the language itself :).

The „MusicArtist“ model class

Thinking about the class itself and keeping our example from above in mind, we could say, that a music artist has the following properties. For sure, it’s just for our example and I’m trying to stay as easy as possible, so feel free to change anything you would like to.

using System;

namespace WpfListViewExampleCs.Models;

public class MusicArtist
{

    public string FirstName { get; set; }

    public string LastName { get; set; }

    public DateTime Birthday { get; set; }

    public MusicArtist(string firstName, string lastName, DateTime birthday)
    {
        FirstName = firstName;
        LastName = lastName;
        Birthday = birthday;
    }
}

Imports System

Namespace WpfListViewExampleCs.Models

    Public Class MusicArtist

        Public Property FirstName As String

        Public Property LastName As String

        Public Property Birthday As DateTime

        Public Sub New(firstName As String, lastName As String, birthday As DateTime)
            Me.FirstName = firstName
            Me.LastName = lastName
            Me.Birthday = birthday
        End Sub

    End Class

End Namespace

In my example here, the music artist has two properties for the name, meaning a first- and a lastname. I don’t like the „name“ only approach, as you can’t easily separate the names in some situations. Well, I mean yeah, before you mention it: „The Beatles“ isn’t really nicely separatable in this manner, but, welcome to the world of software development. I would say, this isn’t the right moment to argue about this, so feel free – again – to change that as you wish. Additionally I thought about using the birthday property, to show some sort of formatting in the XAML as well.

Displaying bound data inside the WPF ListView

After specifying some kind of model to actually display inside the ListView, we now go ahead and tell the ListView about its datasource. The ListView will then know: „Where can I fetch my data from? What is my data?“.

Preventing a known error

But before, we need to clean up the old code, otherwise we could run into an error like this:

System.InvalidOperationException: „The items collection must be empty before using itemssource“

To avoid this error, you need to remove the manually added items inside our XAML code. You can’t like say: „Hey, fetch the items from this datasource here“ AND put them in manually by XAML. Please go ahead and remove this marked area from the XAML code:

Giving the ListView its datasource

In the next step, we will actually care for some items being displayed. For this, we will use the DataSource property of the ListView and bind to some property from our ViewModel. Don’t be scared, if you don’t know what a ViewModel is! Maybe this is another chance, to refer to my blog post considering the MVVM pattern.

<ListView ItemsSource="{Binding MusicArtists}">
<!-- rest of the listview.. -->
</ListView>

We won’t create a separate ViewModel right now, for this simple example, we will use the MainWindow itself. This is pretty much easier at this point and it won’t push you too far away from the actual topic. Never the less, we still need a bindable property inside our MainWindow, which we are going to create, now.

Creating a bindable property

To create the announced property, just build some normal property inside your MainWindow (for example) called „MusicArtists“. This could look like the following code, keep in mind, that we should use something which implements the „INotifyCollectionChanged“ interface. But yes, I hear you, this should be a topic for another blog post, so just take it like that for now.

Next, create that property called „MusicArtists“ of type of „ObservableCollection“, with the generic type argument „MusicArtist“. We could also just make it like readonly, but those are fine tuning things, which aren’t necessary right now.

The last important step is, to say: „Hey, MainWindow, your DataContext is actually.. you!“. Then the MainWindow will know where to find the corresponding „MusicArtists“, which we are going to bind very soon from the XAML side. Take a look at the following example XAML code:

using System;
using System.Collections.ObjectModel;
using System.Windows;
using WpfListViewExampleCs.Models;

namespace WpfListViewExampleCs;

/// <summary>
/// Interaction logic for MainWindow.xaml
/// </summary>
public partial class MainWindow : Window
{

    public ObservableCollection<MusicArtist> MusicArtists { get; set; }

    public MainWindow()
    {
        InitializeComponent();
        MusicArtists = new ObservableCollection<MusicArtist>();
        DataContext = this;
    }
}

Imports System
Imports System.Collections.ObjectModel
Imports System.Windows
Imports WpfListViewExampleCs.Models

Namespace WpfListViewExampleCs

    Public Partial Class MainWindow
        Inherits Window

        Public Property MusicArtists As ObservableCollection(Of MusicArtist)

        Public Sub New()
            InitializeComponent()
            MusicArtists = New ObservableCollection(Of MusicArtist)()
            DataContext = Me
        End Sub

    End Class

End Namespace

Filling up some data

Currently, the ListView wouldn’t be able to display much, because there just aren’t no items inside the „MusicArtists“, yet. So in the next step we are going to fill up some items, to make the ListView be able to display those. This is the reason, why we added a quick constructor inside the „MusicArtist“ class: Creating quick example artists.

Let’s re-create the MainWindow constructor for this:

// rest of the MainWindow code behind file

    public MainWindow()
    {
        InitializeComponent();
        MusicArtists = new ObservableCollection<MusicArtist>();
        MusicArtists.Add(new MusicArtist("Jimmy", "Hendrix", new DateTime(1942, 11, 27)));
        MusicArtists.Add(new MusicArtist("Michael", "Jackson", new DateTime(1958, 8, 29)));
        MusicArtists.Add(new MusicArtist("The", "Beatles", new DateTime(1960, 1, 1)));
        DataContext = this;
    }

// rest of the MainWindow code behind file

' rest of the MainWindow code behind file

Public Sub New()
    InitializeComponent()
    MusicArtists = New ObservableCollection(Of MusicArtist)()
    MusicArtists.Add(New MusicArtist("Jimmy", "Hendrix", New DateTime(1942, 11, 27)))
    MusicArtists.Add(New MusicArtist("Michael", "Jackson", New DateTime(1958, 8, 29)))
    MusicArtists.Add(New MusicArtist("The", "Beatles", New DateTime(1960, 1, 1)))
    DataContext = Me
End Sub

' rest of the MainWindow code behind file

But it’s displaying rubbish now?

If you are looking at the current results, you would pretty much only see rubbish. If you didn’t look until now, please watch the following screenshot, then you probably will. The items are more or less being displayed, but there’s only something like „Blabla.Bla.MusicArtist“ written.

The reason for that is, that the corresponding ListViewItem actually knows: „Hey, there is something called MusicArtist“. But it’s also asking itself: „well, how am I supposed to display this? Property A, B, C, WHAT!?“. In the end it thinks: „You know what, dev? I’m just going to display THAT over here“.

By „that“ I’m meaning the complete path to the corresponding class instance type. We are having a class called „MusicArtist“ inside our project called „WpfListViewExampleCs“ AND inside the „Models“ namespace. So this is basically why that „rubbish“ comes out of it, it displays the complete namespace to class path!

Overriding that „default-rubbish“

Before we are going to use the final solution for this, I first want to explain and show you, how you could potentially solve it at this point. Please keep in mind, that this solution depends on your usecase! Usually, if you want to display like „multiple columns“, you would actually need – well – multiple columns.

In the image from above, you are seeing the default object class „ToString“ output. To change it, you can just override it in your derived class – being the „MusicArtist“-class like in a second. Hint: I’m using the newer, shorter version of the overriding functionality. This means, no body parantheses and an arrow (for C#), as well as string interpolation (for both languages).

You could add this to the „MusicArtist“ class:

// rest of the MusicArtist class

public override string ToString()
    => $"{FirstName} {LastName}";

// rest of the MusicArtist class

' rest of the MusicArtist class

Public Overrides Function ToString() As String
    Return $"{FirstName} {LastName}"
End Function

' rest of the MusicArtist class

So the current / new output would look like this:

Using the ListViews „View“ Property creating columns

After cleaning up that „namespace and class“-mess we saw in the last section, we now can go the last step (I think). Currently, our ListView is only displaying some kind of single dimensioned data, which is not thaaaat bad, but I guess bad for multi-dimensioned data? What if I wanted to have some sort of separated columns for first and last name? This is exactly, where the so called „View“-property of the WPF ListView comes into play!

But why a ListView, why no DataGrid instead?

Sure, you could ask yourself: „Why would I use a ListView, when I could use a DataGrid instead?“. The answer is: „It depends“, yeah, I hate those answers as well.. Usually there’s one rule floating around in the internet: Use a DataGrid, if you need editing, use a ListView otherwise – bang. I would pretty much love going deeper into this topic, but well, I think this post is already too big, isn’t it?

Specifying a „View“-template

To start creating those columns we talked about, we need to specify some sort of template for the View property. But it’s not a usual „DataTemplate“, it’s something more special, lemme give you an example. The basic view provided from WPF itself, is something called a „GridView“. I mean, the name pretty much suggests what it is. If needed, you could create something similiar for your own needs, but again, I think this would blow up this post even more..

So let’s stick with the basic GridView for now. Back into your MVVM prepared ListView, we can now provide a GridView template for our ListView. Watch out for that nice string format functionality, where I specified a custom format for that birthday binding. Basically all you have to do is, providing the columns you want, with a header of your choice. Then you need to tell the ListViewItem, where it should pull the data from (being the DisplayMemberPath-Binding).

            <ListView ItemsSource="{Binding MusicArtists}">
                <ListView.View>
                    <GridView>
                        <GridView.Columns>
                            <GridViewColumn Header="FirstName" DisplayMemberBinding="{Binding FirstName}" />
                            <GridViewColumn Header="LastName" DisplayMemberBinding="{Binding LastName}" />
                            <GridViewColumn Header="Birthday" DisplayMemberBinding="{Binding Birthday, StringFormat={}{0:dd.MM.yyyy}}" />
                        </GridView.Columns>
                    </GridView>
                </ListView.View>
            </ListView>

And finally, you end up having this nice thing here:

Adding, removing, etc. the MVVM way – preparations

Because it’s a bit harder, I saved this topic (and other) for the end of this blog post. You actually need some sort of „ICommand“ implementation, which we won’t cover here, but I will give you the example code needed. There will be another blog post about those commands in english, currently, it’s only available in german, sorry.

A DelegateCommand base class

Please go ahead and create another folder inside your project, called „Utils„. We will deposit a small class over there, which helps us with the buttons in MVVM style. The class I’m talking about looks like this, it’s a basic implementation of a delegated action (with check) for the ICommand-interface:

using System.Windows.Input;
using System;

namespace Utils
{
    public class DelegateCommand : ICommand
    {
        private Action<object?> _action;

        private Func<object?, bool>? _canExecute;

        public DelegateCommand(Action<object?> action)
        {
            _action = action;
        }

        public DelegateCommand(Action<object?> action, Func<object?, bool> canExecute)
        {
            _action = action;
            _canExecute = canExecute;
        }

        public void Execute(object? parameter)
        {
            _action(parameter);
        }

        public bool CanExecute(object? parameter)
        {
            if (_canExecute == null)
                return true;
            return _canExecute(parameter);
        }

        public void RaiseCanExecuteChanged()
        {
            CanExecuteChanged?.Invoke(this, EventArgs.Empty);
        }

        public event EventHandler? CanExecuteChanged;
    }
}

Namespace Utils
    Public Class DelegateCommand
        Implements ICommand
        Private _action As Action(Of Object)
        Private _canExecute As Func(Of Object, Boolean)
        Sub New(action As Action(Of Object))
            _action = action
        End Sub
        Sub New(action As Action(Of Object), canExecute As Func(Of Object, Boolean))
            _action = action
            _canExecute = canExecute
        End Sub
        Public Sub Execute(parameter As Object) Implements ICommand.Execute
            ' führt unsere von außen mitgegebene Aktion aus und übergibt auch den Parameter
            _action(parameter)
        End Sub
        Public Function CanExecute(parameter As Object) As Boolean Implements ICommand.CanExecute
            If _canExecute Is Nothing Then
                Return True
            End If
            Return _canExecute(parameter)
        End Function
        Public Event CanExecuteChanged As EventHandler Implements ICommand.CanExecuteChanged
    End Class
End Namespace

A PropertyChangedBase class

Without going into too much detail, please copy this class and put it into the „Utils“ folder as well. There is a blog post for the INotifyPropertyChanged-interface, but currently it’s only in german. Maybe you could use a browser-translator for now, but I will add the english version soon. So now, please take this class:

using System.Runtime.CompilerServices;
using System.ComponentModel;

namespace Utils;

public abstract class PropertyChangedBase : INotifyPropertyChanged
{
    protected void NotifyOfPropertyChange([CallerMemberName] string? propertyName = null)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
    public event PropertyChangedEventHandler? PropertyChanged;
}

Imports System.ComponentModel
Imports System.Runtime.CompilerServices

Namespace Utils

    Public Class PropertyChangedBase
        Implements INotifyPropertyChanged

        Protected Sub NotifyOfPropertyChange(<CallerMemberName> Optional propertyName As String = Nothing)
            RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(propertyName))
        End Sub

        Public Event PropertyChanged As PropertyChangedEventHandler Implements INotifyPropertyChanged.PropertyChanged

    End Class

End Namespace

Corresponding buttons

Please add something like a StackPanel and 3 Buttons inside of it. There will be one button for adding and one for removing an item at a specific position. The third button will be for removing the selected item. At this point, we will also those commands, please have a look at the following XAML. Please pardon me for not making this visually appealing, it’s only for its functional purpose.

Keep in mind, that you also need to create 3 new properties of type of „DelegateCommand“, 1 for each command, being:

• AddItemCommand
• RemoveItemCommand
• RemoveItemAtIndexCommand

        <GroupBox Header="Music stars" Padding="8" Width="400" VerticalAlignment="Center" HorizontalAlignment="Center">
            <StackPanel>
                <ListView SelectedItem="{Binding SelectedMusicArtist}" ItemsSource="{Binding MusicArtists}">
                    <ListView.View>
                        <GridView>
                            <GridView.Columns>
                                <GridViewColumn Header="FirstName" DisplayMemberBinding="{Binding FirstName}" />
                                <GridViewColumn Header="LastName" DisplayMemberBinding="{Binding LastName}" />
                                <GridViewColumn Header="Birthday" DisplayMemberBinding="{Binding Birthday, StringFormat={}{0:dd.MM.yyyy}}" />
                            </GridView.Columns>
                        </GridView>
                    </ListView.View>
                </ListView>
                <StackPanel Orientation="Horizontal" Margin="0 12 0 0" HorizontalAlignment="Right">
                    <Button Command="{Binding AddItemCommand}" Content="Add item" Margin="0 0 8 0" />
                    <Button Command="{Binding RemoveItemCommand}" Content="Remove item" Margin="0 0 8 0" />
                    <Button Command="{Binding RemoveItemAtIndexCommand}" Content="Remove item at index" />
                </StackPanel>
            </StackPanel>
        </GroupBox>

The „new“ UI now looks like this:

The MainViewModel

Now create a new folder called „ViewModels“ and a „MainViewModel“ class inside. Let the „MainViewModel“ class inherit from the „PropertyChangedBase“ you copied from the previous paragraph. The view (code behind) file should now be abandoned as it’s getting too much otherwise.

Over here we fully implemented the „SelectedMusicArtist“-property to actually tell the „RemoveItemCommand“: „Hey, here was something selected, check if you can be executed now“. We’re subscribing to the „CollectionChanged“ event of the ObservableCollection as well. This way, we can also refresh the commands state, when the collection is changed.

In the next steps, we are going to instantiate the commands and therefore telling them, what to do and when.

using System;
using System.Collections.ObjectModel;
using System.Collections.Specialized;
using Utils;
using WpfListViewExampleCs.Models;

namespace WpfListViewExampleCs.ViewModels;

public class MainViewModel : PropertyChangedBase
{

    public ObservableCollection<MusicArtist> MusicArtists { get; set; }

    private MusicArtist? _selectedMusicArtist;

    public MusicArtist? SelectedMusicArtist
    {
        get => _selectedMusicArtist;
        set
        {
            if (_selectedMusicArtist == value)
                return;
            _selectedMusicArtist = value;
            RemoveItemCommand.RaiseCanExecuteChanged();
        }
    }

    public DelegateCommand AddItemCommand { get; set; }

    public DelegateCommand RemoveItemCommand { get; set; }

    public DelegateCommand RemoveItemAtIndexCommand { get; set; }

    public MainViewModel()
    {
        MusicArtists = new ObservableCollection<MusicArtist>();
        MusicArtists.CollectionChanged += MusicArtists_CollectionChanged;
        MusicArtists.Add(new MusicArtist("Jimmy", "Hendrix", new DateTime(1942, 11, 27)));
        MusicArtists.Add(new MusicArtist("Michael", "Jackson", new DateTime(1958, 8, 29)));
        MusicArtists.Add(new MusicArtist("The", "Beatles", new DateTime(1960, 1, 1)));
    }

    private void MusicArtists_CollectionChanged(object? sender, NotifyCollectionChangedEventArgs e)
    {
        RemoveItemCommand.RaiseCanExecuteChanged();
        RemoveItemAtIndexCommand.RaiseCanExecuteChanged();
    }

}

Imports System
Imports System.Collections.ObjectModel
Imports System.Collections.Specialized
Imports Utils
Imports WpfListViewExampleCs.Models

Namespace WpfListViewExampleCs.ViewModels

    Public Class MainViewModel
        Inherits PropertyChangedBase

        Public Property MusicArtists As ObservableCollection(Of MusicArtist)

        Private _selectedMusicArtist As MusicArtist?

        Public Property SelectedMusicArtist As MusicArtist?
            Get
                Return _selectedMusicArtist
            End Get
            Set(ByVal value As MusicArtist?)
                If _selectedMusicArtist = value Then Return
                _selectedMusicArtist = value
                RemoveItemCommand.RaiseCanExecuteChanged()
            End Set
        End Property

        Public Property AddItemCommand As DelegateCommand

        Public Property RemoveItemCommand As DelegateCommand

        Public Property RemoveItemAtIndexCommand As DelegateCommand

        Public Sub New()
            MusicArtists = New ObservableCollection(Of MusicArtist)()
            AddHandler MusicArtists.CollectionChanged, AddressOf MusicArtists_CollectionChanged
            MusicArtists.Add(New MusicArtist("Jimmy", "Hendrix", New DateTime(1942, 11, 27)))
            MusicArtists.Add(New MusicArtist("Michael", "Jackson", New DateTime(1958, 8, 29)))
            MusicArtists.Add(New MusicArtist("The", "Beatles", New DateTime(1960, 1, 1)))
        End Sub

        Private Sub MusicArtists_CollectionChanged(ByVal sender As Object?, ByVal e As NotifyCollectionChangedEventArgs)
            RemoveItemCommand.RaiseCanExecuteChanged()
            RemoveItemAtIndexCommand.RaiseCanExecuteChanged()
        End Sub

    End Class

End Namespace

Modern alternative (.NET 6+): CommunityToolkit.Mvvm

Writing DelegateCommand and PropertyChangedBase manually works perfectly fine 👉 and understanding how they work is exactly why we did it this way. But in 2026, you would typically reach for the CommunityToolkit.Mvvm NuGet package instead.

It ships source generators like [ObservableProperty] and [RelayCommand], which produce the same boilerplate automatically at compile time, meaning less code to write and maintain.

Compare the two approaches with these small code snippets:

❌ Manual (what we did above)

private MusicArtist? _selectedMusicArtist;
public MusicArtist? SelectedMusicArtist {
    get => _selectedMusicArtist;
    set { _selectedMusicArtist = value; NotifyOfPropertyChange(); }
}

✅ CommunityToolkit.Mvvm

[ObservableProperty]
private MusicArtist? _selectedMusicArtist;

Well worth a look once you are comfortable with the concepts above!

Assign a ViewModel to the MainWindow

To be able to this all work, make sure, you set an appropriate ViewModel for your MainWindow. Otherwise, the binding system wouldn’t know, where to search for your bindings. This is done by adding this code to your MainWindow XAML file:

<!-- create a namespace mapping at the top of your file -->
xmlns:vm="clr-namespace:WpfListViewExampleCs.ViewModels"

<!-- Set the DataContext MainViewModel instance by XAML -->
<Window.DataContext>
    <vm:MainViewModel />
</Window.DataContext>

How to add WPF ListView items with MVVM

After you got our little helper class from above inside your „Utils“ folder and everything else ready, we can now continue. Adding items is now kinda different, because our items are actually bound and not just simple strings. Our commands wants at least to know, what it should do, when executed. We can pass a function, to let the command determine, if it can be executed. I mean, we don’t want a „remove selected item“ to happen, when there’s no item, right?

The following code is needed for the actual functionality: Instantiate the command inside the constructor (don’t forget to take the command property from above!).

    // other properties

    public DelegateCommand AddItemCommand { get; set; }

    public MainViewModel()
    {
        AddItemCommand = new DelegateCommand(AddItem);

        // list instantiation etc..
    }

    // the delegate function to be executed on click
    private void AddItem(object? parameter)
    {
        // adding miley cyrus, as we have no dynamic dialog, as it's not a part of this here..
        MusicArtists.Add(new MusicArtist("Miley", "Cyrus", new DateTime(1992, 11, 23)));
    }

    ' other properties
   
    Public Property AddItemCommand As DelegateCommand

    Sub New()
        AddItemCommand = new DelegateCommand(AddItem);

        ' list instantiation etc..
    End Sub

    Private Sub AddItem(parameter As Object)
        MusicArtists.Add(New MusicArtist("Miley", "Cyrus", New DateTime(1992, 11, 23)))
    End Sub

Removing the selected item MVVM style

The important thing here is, that we can only remove a selected item, if there is actually one selected. Please check the „SelectedMusicArtist“-property from the above MainViewModel for this. If the selected item (therefore the SelectedMusicArtist) changes, we tell the command to refresh.

    // other properties

    public DelegateCommand RemoveItemCommand { get; set; }

    public MainViewModel()
    {
        RemoveItemCommand = new DelegateCommand(RemoveItem, CanRemoveItem);

        // list instantiation etc..
    }

    private void RemoveItem(object? parameter)
    {
        // we should know that SelectedMusicArtist isn't null, therefore the !
        MusicArtists.Remove(SelectedMusicArtist!);
    }

    private bool CanRemoveItem(object? parameter)
    {
        return SelectedMusicArtist != null;
    }

    ' other properties
   
    Public Property RemoveItemCommand As DelegateCommand

    Sub New()
        RemoveItemCommand = new DelegateCommand(RemoveItem, CanRemoveItem);

        ' list instantiation etc..
    End Sub

    Private Sub RemoveItem(parameter As Object)
        MusicArtists.Remove(SelectedMusicArtist)
    End Sub

    Private Function CanRemoveItem(parameter As Object) As Boolean
        Return SelectedMusicArtist IsNot Nothing
    End Function

Deleting an item by index, MVVM like

In the last example, we do pretty much the same, but with some hardcoded index, just as an example!

    // other properties

    public DelegateCommand RemoveItemAtIndexCommand { get; set; }

    public MainViewModel()
    {
        RemoveItemAtIndexCommand = new DelegateCommand(RemoveItemAtIndex, CanRemoveItemAtIndex);

        // list instantiation etc..
    }

    private void RemoveItemAtIndex(object? parameter)
    {
        // we need at least one item inside
        MusicArtists.RemoveAt(0);
    }

    private bool CanRemoveItemAtIndex(object? parameter)
    {
        return MusicArtists.Count > 0;
    }

    ' other properties
   
    Public Property RemoveItemAtIndexCommand As DelegateCommand

    Sub New()
        RemoveItemAtIndexCommand = new DelegateCommand(RemoveItemAtIndex, CanRemoveItemAtIndex);

        ' list instantiation etc..
    End Sub

    Private Sub RemoveItemAtIndex(parameter As Object)
        MusicArtists.RemoveAt(0)
    End Sub

    Private Function CanRemoveItemAtIndex(parameter As Object) As Boolean
        MusicArtists.Count > 0
    End Function

Conclusion – WPF ListView Control

If you want to have a control, which is able to display things in like a list, being able to select one or more items out of it, the ListView is possibly your choice. When thinking about: „Should I use a ListView or a DataGrid“, you should choose the ListView, if editing is not a concern. As mostly always, you have the option to go for the code behind, or the MVVM approach, I would personally always choose the MVVM one. It seems much cleaner for my personal preferences and doesn’t mix up UI with business code. Feel free to leave any comment on how to improve this article, or if I may explained something wrong.

FAQ

Downloads

If you need quick and ready to use examples, just go ahead and download the ones you need. Maybe I’ll add some more later.

Der Beitrag The WPF ListView Control – the complete Guide in 2026 erschien zuerst auf Robert Skibbe.

Nutze WPF Commands, vermeide „Button1_Click“ & Co.

Im heutigen Beitrag schauen wir uns das Thema „eigene WPF Commands“, bzw. die passende Schnittstelle „ICommand“ an. Damit werden wir der besonders aus Winforms-Zeiten (Windows Forms) bekannten Vermischung von Design und Quellcode entfliehen. Dazu schauen wir uns erst die Basis der „ICommand“-Schnittstelle an und erstellen auch anschließend eine wiederverwendbare Klasse – wir haben schließlich keinen Bock, alles 10x zu schreiben! Um alles zu verstehen, geht es hier und da natürlich noch einmal Richtung Details, aber gut, so viel Zeit muss sein, wenn man nicht nur „Copy & Paste“-Master sein möchte :)!

💡 Hinweis: Nutze gerne das Inhaltsverzeichnis, um an passende Stellen zu springen, da es sich hierbei um ein ausführliches Thema handelt, Welches man nicht „mal eben“ besprechen kann. Falls Du z. B. nur eine wiederverwendbare Command-Basisklasse benötigst, findest Du Diese weiter unten. Vielleicht möchtest Du auch einen Blick auf die Downloads-Sektion werfen?

In diesem Beitrag werden wir synchrone Commands besprechen, die asynchrone Variante werden wir im Detail, in einem der nächsten Beiträge angehen. Ebenso wird das Thema „Login“ nur als Beispiel thematisiert und nicht vollständig realisiert. Allgemein möchte ich erreichen, dass Du hier rausgehen und „Nice, ich habe Commands verstanden“ sagen kannst :)!

Kurzfassung – .NET WPF Commands in MVVM

Wenn Du es eilig hast, hier die Kurzfassung über .NET MVVM Commands in WPF:

• Ersetze z. B. die typischen Click-Handler von Buttons durch passende Datenbindungen an sogenannte Commands. Beachte jedoch, dass Commands nicht nur von Buttons, sondern z. B. auch von Kontextmenüs unterstützt werden!
• Dazu musst Du Deinem View in erster Linie einen Datenkontext geben, damit es weiß, woher es die „Dinge“ durch Datenbindung bekommen kann.
• Sage in Deinem Button-XAML dann via Command-Eigenschafts-Bindung, dass Du das „LoginCommand“ verwenden möchtest – voilà!
• Implementiere im nächsten Schritt die „ICommand„-Schnittstelle und erstelle danach in Deinem Datenkontext eine passende, bindbare Eigenschaft, z. B. „LoginCommand“ zur Verfügung.
• Instanziiere die Command-basierte Eigenschaft nun z. B. in Deinem ViewModel–Konstruktor.
• Übergib manuelle oder gebundene Parameter, indem Du an die CommandParameter–Eigenschaft des (z. B.) Buttons bindest.

Damit Du die Implementierung allerdings nicht hunderte Male und für z. B. jeden Knopf wiederholen musst, würde ich Dir eine Abstraktion durch eine Basisklasse vorschlagen. Eine derartige Klasse (für VB.NET & C#) findest Du natürlich auch hier im Beitrag. Scrolle dazu einfach zu „eine wiederverwendbare Command-Basisklasse„, oder direkt zu den Downloads.

Beitrag als Video ansehen

Wenn Du diesen Beitrag lieber im Videoformat genießen möchtest, kannst Du natürlich auch das folgende Video (vielleicht auch ergänzend) ansehen. Besonders die Hinweise bezüglich der „PasswordBox“ sind sehr wichtig!

Projekt- und Ordnerstruktur

Bevor wir mit dem eigentlichen Thema „WPF Commands in MVVM“ loslegen können, legen wir uns als Erstes unsere Projektstruktur zurecht. Eine vernünftige Ordner- und Organisationsstruktur ist natürlich nicht nur nützlich, wenn man allein arbeitet, um z. B. immer in den gewohnten Ablauf hineinzukommen. Es hilft uns zusätzlich auch dabei, falls wir mal etwas outsourcen, bzw. jemanden um Hilfe bitten müssen – und das kommt häufig schneller vor, als man denkt! Wer will sich außerdem in seinem eigenen Code immer den Ast absuchen müssen, nur weil es jedes Mal anders aussieht? Keiner!

Natürlich könnte ich jetzt hier auch alles wieder von vorn erzählen, möchte es aber im Sinne des Entwicklers (Don’t repeat yourself – wiederhole dich nicht) vermeiden. Schaue Dir den Basis-Projektaufbau daher gerne in meinem Beitrag „Wie setzt man ein VB.NET, bzw. WPF MVVM-Projekt auf“ an.

Die Rollenverteilung in .NET WPF MVVM

Da dieser Beitrag die Verwendung von Commands im Fokus hat, verstehe bitte, dass ich nicht zu tief in das „Model-View-ViewModel“-Entwurfsmuster selbst abtauchen kann. Allerdings ist für die Verwendung von WPF Commands natürlich ein gewisses Grundverständnis der MVVM-Architektur erforderlich. Besuche für eine erweiterte Erklärung gerne meinen Beitrag zum MVVM-Entwurfsmuster, auch wenn Dieser C#-geprägt ist, sind alle Erkenntnisse natürlich auch bei VB.NET analog.

Grundsätzlich geht es bei dieser Strukturierung von modernen .NET Applikationen (oder auch Applikationen im Allgemeinen) anhand des MVVM-Musters darum, eine saubere Rollentrennung zu erreichen. Insbesondere spricht man hier von der Trennung von Benutzeroberfläche und Geschäftslogik – woran meist verschiedene Personen wie Designer und Entwickler arbeiten. Dies bietet nicht nur die Möglichkeit, sich fast ganz auf seine Rolle konzentrieren zu können, sondern auch ganz andere praktische Vorteile. So erreicht man durch die einfachere Austauschbarkeit von „Views“ und „ViewModels“ etwa eine erhöhte Test- und Wartbarkeit seiner Software im Allgemeinen.

Das View – die Aufgabe des Designers

Je nach Herangehensweise (also View-, oder ViewModel-First) geht z. B. der Designer hin und entwirft nach etwaigen Wireframing-Prozessen die gewünschte Oberfläche mit Hilfe der XAML-Auszeichnungssprache. Mit dem Kunden wurden also ggf. vorherige Absprachen (mit Skizzen – Wireframes) getroffen, Welche das ungefähre Layout und Design zumindest grob bestimmen sollen. Dies kann dann z. B. ohne eine Zeile Code geschrieben zu haben wie gleich folgend aussehen und eine gemeinsame Basis / einen gemeinsamen Konsens bilden. Zugegebenermaßen ist das folgende Beispiel schon eher auf einem „Non-Plus-Ultra“-Level, da man – je nach Unternehmensgröße – eher ein „mach‘ Mal“ geliefert bekommt. Aber gut, träumen darf man als Entwickler noch, oder!?

Wenn unsere Wünsche daher also wahr werden, haben die Designer die Möglichkeit, die skizzierten Wünsche des Kunden relativ unabhängig vom Entwickler (-Team) in XAML umsetzen zu können. Ganz im Stil von WPF und Co. verwendet man hier Datenbindungen, also XAML Binding-Anweisungen, wie z. B.:

<TextBox Text="{Binding WelcomeMessage}" />

Den Designern kann und soll es an dieser Stelle egal sein, wie genau die „WelcomeMessage“ erschaffen und verändert wird, solange Sie daran binden können – ergo sich an die WPF-Mechanismen gehalten wird. Viele verkaufen den utopischen Traum des „Solo-Separat-Entwickelns“ zu gern, allerdings muss natürlich trotzdem Austausch zwischen Entwicklern und Designern stattfinden. Ein „wir arbeiten vollkommen getrennt voneinander“ ist also nicht zu 100% möglich, ABER eben viel viel einfacher. Die Designer können ja schließlich z. B. auch nicht raten, ob unsere „IsSelected“-Eigenschaft nun eben sinnigerweise so, oder „Selected“ heißt. Je öfter man zusammenarbeitet, desto leichter erschließen sich solche Muster natürlich in Zukunft und man kann immer unabhängiger, gar blind zusammenarbeiten.

Der Entwickler, die ViewModels, Geschäftslogik und Co.

Nachdem wir als Entwickler – im Optimalfall – also nun unsere Wireframes bekommen haben, können nun auch wir ziemlich isoliert / separat tätig werden. Wir entwerfen die passenden ViewModel-Klassen zu den gezeigten Oberflächen, Welche „INotifyPropertyChanged“ und Co. verwenden, um durch die Datenbindungen zu kommunizieren. Schaue Dir hierzu gerne meinen Beitrag zum Thema „INotifyPropertyChanged“ an. Bei Bedarf erschaffen wir Test-ViewModels, Welche wir durch die neue Herangehensweise, ohne Probleme und Aufwand austauschen und testen können.

Wie erwähnt möchte ich den Exkurs in Richtung „Model-View-ViewModel-Entwurfsmuster“ nicht zu weit treiben, daher gehe ich hier nicht weiter auf z. B. Models ein. Ich denke sowieso, dass das nicht zielführend wäre, denn zu viel Input ist ja auch schlecht, oder? „Kleine“ Häppchen machen dann schon eher den Appetit :)!

Ein kleines Login-Fenster-Beispiel für WPF Commands

Nach dem kleinen Exkurs von oben, schauen wir uns nun die weitere Reise in Richtung Commands an. Dazu bauen wir uns im nächsten Schritt eine kleine Login-Oberfläche (Achtung, billig..), Welche wie gleich folgend aussehen könnte. Hier werden wir auch direkt aus einer Art Designer-Perspektive agieren, also wir arbeiten in erster Linie „nur“ am XAML-Code selbst.

Wir tun hier einfach mal so, als hätten wir ein passendes Wireframe vom Kunden vorliegen.. Was macht also ggf. in erster Linie eine Login-Oberfläche aus? Naja, wir brauchen:

• Eine Textbox für die Eingabe des Nutzers / E-Mail-Adresse
• Ein Label / Textblock für diese Textbox, sonst weiß der Nutzer nicht was das soll
• Eine PasswordBox für die Eingabe des Passworts (beachte hier die Hinweise)
• Auch hierfür einen Textblock
• Einen Button, wie soll der Benutzer sonst „Login-Versuch durchführen“ triggern
• ggf. weiteren Kram, wie „Passwort vergessen“ – lassen wir hier aber aus..

Bitte bedenke auch an dieser Stelle – wie oben angekündigt –, dass wir hier kein vollständiges Login-Beispiel realisieren können, da der Beitrag auch so schon lang genug wird 😉! Einen Login werde ich ggf. mal in einem anderen Beitrag separat behandeln und dort dann ausführen.

Datenbindungen des Login-Fensters

Nachdem wir im obigen Schritt die grundsätzlich benötigten Steuerelemente angemerkt haben, brauchen wir – für MVVM selbstverständlich – auch passende Datenbindungen. Ansonsten wüssten weder die Textboxen, woher Sie Ihren Text bekommen, oder gar „hinschicken“ sollen. Ebenso hätte der Anmelden-Knopf keine Ahnung, was beim Klick passieren soll (Spoiler: Ein Command ausführen).

Der Designer wird an dieser Stelle hier irgendwie vorher (mit Kunden und Entwicklern) besprochen haben, dass es im ViewModel so etwas namens „User“ geben muss. Dabei handelt es sich genauer genommen um eine String-Eigenschaft, welche den dementsprechenden Text für die Textbox – also den Benutzer – beinhalten muss. Ebenso muss diese Eigenschaft bei Code-technischen Änderungen nach außen kommunizieren, dass Sie sich geändert hat. Dies geht wie vermutlich bekannt über „INotifyPropertyChanged“, was hier allerdings nicht weiter Thema sein wird. Hier nochmal erneut der Hinweis auf meinen „INotifyPropertyChanged“-Beitrag mit „PropertyChanged“-Basisklasse.

Schaue Dir nun einmal den XAML-Code zum Fenster an, beachte, dass Du die obigen „Projekt- und Ordnerstruktur“-Schritte korrekt abgeschlossen hast. Ansonsten wirst Du hier vermutlich Probleme mit Namespace und Co. bekommen. Passe ebenfalls auf, dass Du den Projektnamen umbenennen musst, in meinem Beispiel hieß das Projekt „WpfCommandsVbTutorial“.

Datenkontext (DataContext) setzen

Im ersten Schritt ergänzen wir die folgenden zwei Punkte in den XAML-Code des MainWindows (MainViews).

1. Wir mappen via „xmlns:<name>“ einen Namespace anhand eines Aliases:

<!-- ganz oben, im Abschnitt des Window-Tags -->
xmlns:vm="clr-namespace:WpfCommandsVbTutorial.ViewModels"

2. Wir geben dem jeweiligen View einen Datenkontext (DataContext-Eigenschaft des Windows) über XAML. Wie Du vielleicht weißt, wäre dies auch via „Code behind“-Datei möglich, ich habe mich hier für die XAML Variante entschieden:

<!-- im "Content" des Windows -->
<Window.DataContext>
    <vm:MainViewModel />
</Window.DataContext>

Du kannst an dieser Stelle übrigens die Styling-relevanten Dinge ignorieren, also praktisch alles, was in „StackPanel.Resources“ z. B. steht. Dies ist nur zur Anschauung erstellt worden und Du solltest Deinen Fokus größtenteils auf die oben aufgelisteten Steuerelemente legen.

💡 Hinweis: Wir werden im weiteren Verlauf noch an der PasswordBox und Co. arbeiten, sowie wichtige Sicherheitsaspekte besprechen. Dies hier ist daher noch nicht die finale Variante! Ebenso fehlt hier auch noch ein wichtiger Punkt bei der Benutzer-Textbox!

<!-- in C#, there's a project prefix before Views -->
<Window x:Class="Views.MainView"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
        xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
        xmlns:local="clr-namespace:WpfCommandsVbTutorial"
        mc:Ignorable="d"
        xmlns:vm="clr-namespace:WpfCommandsVbTutorial.ViewModels"
        Title="MainWindow" Background="DarkOrange" Height="450" Width="800" WindowStartupLocation="CenterScreen">
    
    <Window.DataContext>
        <vm:MainViewModel />
    </Window.DataContext>

    <Grid>
        <StackPanel Width="200" VerticalAlignment="Center" HorizontalAlignment="Center">
            <StackPanel.Resources>
                <Style TargetType="TextBlock">
                    <Setter Property="Foreground" Value="WhiteSmoke" />
                    <Setter Property="FontWeight" Value="SemiBold" />
                    <Setter Property="FontSize" Value="16" />
                    <Setter Property="Margin" Value="0 0 0 4" />
                </Style>
                <Style TargetType="TextBox">
                    <Setter Property="FontSize" Value="16" />
                    <Setter Property="Margin" Value="0 0 0 4" />
                    <Setter Property="Effect">
                        <Setter.Value>
                            <DropShadowEffect ShadowDepth="2" Direction="330" Color="Black" Opacity="0.5" BlurRadius="1"/>
                        </Setter.Value>
                    </Setter>
                </Style>
                <Style TargetType="PasswordBox">
                    <Setter Property="FontSize" Value="16" />
                    <Setter Property="Margin" Value="0 0 0 8" />
                    <Setter Property="Effect">
                        <Setter.Value>
                            <DropShadowEffect ShadowDepth="2" Direction="330" Color="Black" Opacity="0.5" BlurRadius="1"/>
                        </Setter.Value>
                    </Setter>
                </Style>
            </StackPanel.Resources>
            <TextBlock Text="Benutzer" />
            <TextBox Text="{Binding User}" />
            <TextBlock Text="Passwort" />
            <!-- die Passwordbox kann nicht so einfach gebunden werden und da dies nicht
Bestandteil dieses Beitrages ist, werde ich dies auf einen anderen Beitrag verlagern.
Konzentriere Dich bitte auf die Aspekte von WPF Commands :) -->
            <PasswordBox />
            <Button Command="{Binding LoginCommand}" Content="Anmelden" FontSize="16" />
        </StackPanel>
    </Grid>
</Window>

Das ViewModel zur Oberfläche

Bevor wir mit den WPF Commands im Detail fortfahren können, müssen wir noch etwas bauen, was Diese letztendlich beinhaltet. Hierbei rede ich natürlich von einer ViewModel-Klasse, Welche alles Notwendige für die Datenbindungen bereitstellt. Neben dem oben im XAML erwähnten „LoginCommand“, bezieht sich dies natürlich auch auf die Eigenschaften wie „User“ und „Password“.

Wenn wir dies auslassen würden, könnte die grafische Oberfläche Ihre dort empfangenen Änderungen nie via Datenbindungen an die dahinter liegenden ViewModel-Eigenschaften weitergeben. Somit hätten wir auch in unserer Geschäftslogik (innerhalb des ViewModels) nie die Chance, damit tatsächlich arbeiten zu können. Wie Du Dir also vorstellen kannst, wäre eine Anmeldung ohne z. B. typische Benutzer- und Passwort-Kombination ziemlich schwierig.

Fehlermeldungen bei fehlender / falscher Datenbindung

Falls Du an dieser Stelle also eine der typischen Binding-Fehlermeldungen bekommen solltest, kannst Du Dir nun vorstellen woran das liegt. Du hast vermutlich vergessen, den DataContext mit einer passenden ViewModel-Instanz zu befüllen – wie wir es im gleich folgenden Schritt tätigen werden. Typische Fehlermeldung sehen ungefähr so aus, also hier wurde z. B. die „User“-Eigenschaft nicht auf der „MainViewModel“-Instanz gefunden:

Falls Du also eine derartige Fehlermeldung bekommst, stelle sicher, dass die Eigenschaft „User“ in Deinem Viewmodel existiert. Es kann hier aber auch vorkommen, dass z. B. gar kein Fehler kommt und dennoch nichts passiert. Dies ist z. B. der Fall, wenn Du vergisst, den DataContext überhaupt zu setzen! Denke daran, dass wir das hier im View selbst, also via XAML-Code weiter oben getan haben!

Das (erste) MainViewModel erstellen

Erstelle für die weitere Vorgehensweise in Richtung WPF Commands nun einmal bitte eine Klasse namens „MainViewModel“ in Deinem „ViewModels“-Ordner. Unsere ViewModel-Klasse wird hierbei von der „PropertyChangedBase“-Basisklasse erben, damit wir die dort zurechtgeschriebene Funktionalität weiterverwenden können. Somit sparen wir es uns, die „INotifyPropertyChanged“-Schnittstelle immer und immer wieder manuell implementieren zu müssen. Kopiere Dir die Basisklasse ruhig von diesem Beitrag hier.

Nun das MainViewModel, wundere Dich bitte nicht, dass dort schon anderer Kram drin steht, aber ich möchte Dir diesen Batzen gleich nicht noch 3x um die Ohren hauen. Wir nehmen dies daher als Basis und arbeiten uns von dort aus weiter durch den Code. Es fehlen hier auch noch die ein odere andere Funktion, sowie eine Klasse für die Commands, Welche wir natürlich noch erstellen.

Imports WpfCommandsVbTutorial.Utils

Namespace ViewModels

    Public Class MainViewModel
        Inherits PropertyChangedBase

        Private _user As String

        Public Property User As String
            Get
                Return _user
            End Get
            Set(value As String)
                If _user = value Then
                    Return
                End If
                _user = value
                NotifyOfPropertyChange()
            End Set
        End Property

        Private _password As String

        Public Property Password As String
            Get
                Return _password
            End Get
            Set(value As String)
                If _password = value Then
                    Return
                End If
                _password = value
                NotifyOfPropertyChange()
            End Set
        End Property

        Public Property LoginCommand As LoginCommand

        Sub New()
            LoginCommand = New LoginCommand()
        End Sub

    End Class

End Namespace

using Utils;

namespace ViewModels;

public class MainViewModel : PropertyChangedBase
{
    private string _user;

    public string User
    {
        get => _user;
        set
        {
            if (_user == value)
                return;
            _user = value;
            NotifyOfPropertyChange();
        }
    }

    private string _password;

    public string Password
    {
        get => _password;
        set
        {
            if (_password == value)
                return;
            _password = value;
            NotifyOfPropertyChange();
        }
    }

    public LoginCommand LoginCommand { get; set; }

    public MainViewModel()
    {
        LoginCommand = new LoginCommand();
    }

}

Die üblichen Mechanismen

Zuerst einmal siehst Du im obigen MainViewModel-Code die 3 wichtigsten Eigenschaften für unser Login-Fenster:

1. Die User-Eigenschaft
2. Die Password-Eigenschaft
3. Die LoginCommand-Eigenschaft

Bis auf das „LoginCommand“ sind alle Eigenschaften sogenannte „voll implementierte“-Eigenschaften, Sie haben also einen von uns manuell implementierten Getter und Setter. Dies geschieht deshalb, weil wir im Setter sagen müssen: „Hey, es hat sich Code-seitig z. B. der User geändert“. Das passiert einerseits, wenn wir einen gespeicherten Zugang von der Festplatten laden, aber auch, wenn der Benutzer des Programms eine Eingabe in der Textbox macht – besonders hierzu aber gleich noch etwas! Andererseits können wir dem Command das dann auch noch explizit mitteilen, denn warum sollte man sich anmelden können, wenn, wenn z. B. gar kein Benutzername eingegeben wurde? Dazu kommen wir aber noch..

Etwas anders sieht es wie schon gesagt beim „LoginCommand“ aus, denn Dieses wird nach der Instanziierung nicht mehr geändert. Hier reicht also eine sogenannte automatisch implementierte Eigenschaft aus.

Der erste Command-Versuch

An dieser Stelle werden wir den ersten Versuch Richtung eigener WPF Commands starten. Wir werden dafür das sogenannte „ICommand“-Interface (manuell) implementieren – später vereinfacht, keine Sorge! Erstelle also nun bitte eine weitere Klasse (ohne Datei) namens „LoginCmd“, Diese kannst Du für den Anfang einfach innerhalb des Wurzelverzeichnisses Deines Projektes ablegen. Dies werden wir selbstverständlich später ändern, brauchen wir aber am Anfang zur reinen Demonstration.

Schreibe für VB.NET anschließend – wie für Schnittstellen-Implementierungen üblich – einfach „Implements INotifyPropertyChanged“ unter die beginnende Klassendefinition: „Public Class LoginCommand“. Für C# kannst Du ein „: INotifyPropertyChanged“ hinter den Klassennamen schreiben. In beiden Fällen kannst Du dann die Imports durch die Visual Studio-Hilfe durchführen. Alternativ kannst Du auch Strg+“.“ drücken und die dann erscheinenden Vorschläge durchführen.

Imports WpfCommandsVbTutorial.Utils

Namespace ViewModels

    Public Class MainViewModel
        Inherits PropertyChangedBase

        ' restlicher MainViewModel-Code

        Public Property LoginCommand As LoginCommand

        Sub New()
            LoginCommand = New LoginCommand()
        End Sub

        Public Class LoginCmd
            Implements ICommand

            Public Sub Execute(parameter As Object) Implements ICommand.Execute
                Throw New NotImplementedException()
            End Sub

            Public Function CanExecute(parameter As Object) As Boolean Implements ICommand.CanExecute
                Throw New NotImplementedException()
            End Function

            Public Event CanExecuteChanged As EventHandler Implements ICommand.CanExecuteChanged

        End Class

    End Class

End Namespace

using System.Windows.Input;
using System;
using Utils;

namespace ViewModels;

public class MainViewModel : PropertyChangedBase
{

    // restlicher MainViewModel-Code

    public LoginCmd LoginCommand { get; set; }

    public MainViewModel()
    {
        LoginCommand = new LoginCmd();
    }

    public class LoginCmd : ICommand
    {

        public void Execute(object? parameter)
        {
            throw new NotImplementedException();
        }

        public bool CanExecute(object? parameter)
        {
            throw new NotImplementedException();
        }

        public event EventHandler? CanExecuteChanged;

    }
}

Was soll bei Ausführung des WPF Commands passieren?

Um dem Command sagen zu können: „Hey, wenn Du ausgeführt wirst, soll xy passieren“, müssen wir nun eine bestimmte Methode implementieren. Dabei handelt es sich um die „Execute“-Methode, der „ICommand“-Schnittstelle. Dort drin können wir beispielsweise einmal einen Anmeldevorgang simulieren, mehr wird denke ich zu kompliziert sein, also etwa mit Services zu kommunizieren, usw. Das werde ich aber mit Sicherheit noch in einem anderen Beitrag vertiefen!

Die „Execute“-Methode sieht dann grundsätzlich erstmal wie folgt aus:

Public Class LoginCommand
    Implements ICommand

    Public Sub Execute(parameter As Object) Implements ICommand.Execute
        ' hier kommt rein, was beim Klick passieren soll
        Debug.WriteLine("Melde mich an")
    End Sub

    ' restlicher Code..

End Class

public class LoginCommand : ICommand
{

    public void Execute(object? parameter)
    {
        // hier kommt rein, was beim Klick passieren soll
        Debug.WriteLine("Melde mich an");
    }

    // restlicher Code..

}

Kann das WPF Command überhaupt ausgeführt werden?

Nachdem wir die eine „Execute“-Methode implementiert und somit beschrieben haben, was beim Ausführen des Commands passieren soll, geht’s nun mit dem „kann ich das ausführen“ weiter. Es wäre ja z. B. blöd, wenn der Benutzer der Software den „Anmelden“-Knopf spammen könnte. Stattdessen sollte man den Button deaktivieren, während z. B. eine Art Sperre stattfindet. Dazu müssen wir eine Funktion namens „CanExecute“ implementieren, Welche – wie der Name schon sagt – bestimmt, ob das jeweilige Command gerade ausgeführt werden kann.

Der Code dazu könnte wie folgt aussehen, also, dass z. B. das Command nach 3 fehlerhaften Login-Versuchen gesperrt ist.

Public Class LoginCommand
    Implements ICommand

    Private _failedAttempts As Integer

    Public Sub Execute(parameter As Object) Implements ICommand.Execute
        ' simulate failed login attempt
        _failedAttempts += 1
    End Sub

    Public Function CanExecute(parameter As Object) As Boolean Implements ICommand.CanExecute
        Return _failedAttempts < 3
    End Function

    Public Event CanExecuteChanged As EventHandler Implements ICommand.CanExecuteChanged

End Class

using System;
using System.Windows.Input;

public class LoginCommand : ICommand
{
    private int _failedAttempts;

    public void Execute(object? parameter)
    {
        // simulate failed login attempt
        _failedAttempts++;
    }

    public bool CanExecute(object? parameter)
    {
        return _failedAttempts < 3;
    }

    public event EventHandler? CanExecuteChanged;

}

Zum Schluss bleibt hier nun noch ein letztes Problem: Das Command wird so gesehen niemals „aktualisiert“. Es wird aktuell leider nicht nach außen bekanntgemacht: „Hey, grafische Oberfläche, evaluiere bitte einmal neu, ob ich ausgeführt werden kann, denn hier hat sich was geändert!“. Somit bleibt das Command aktuell immer ausführbar. Wenn Du stattdessen z. B. initial ein Kriterium hättest – wie z. B. eine Rolle an Nutzern– die den Button nicht drücken dürfen, dann könnte es auch sein, dass der Button permanent grau hinterlegt ist. Keine Sorge, darum kümmern wir uns nun im letzten Schritt!

Neu evaluieren, ob ausgeführt werden kann

Um der grafischen Oberfläche genau dieses Signal a la „Hey, re-evaluiere hier bitte einmal die CanExecute-Funktion“ zu geben, müssen wir nur eins tun: Das Ereignis auslösen, Welches bewusst von der „ICommand“-Schnittstelle dafür vorgegeben wurde, namens „CanExecuteChanged“. Aktuell ist dies noch relativ einfach, da wir alles was wir dafür benötigen, innerhalb der Command-Instanz selbst haben.

Was ich meine, ist die Anzahl an fehlgeschlagenen Anmelde-Versuchen, Welche wir in der Zeile 3 deklariert haben. Wir müssten also eigentlich immer das „CanExecuteChanged“-Ereignis auslösen, wenn sich diese Variable ändert. Gleich kommen wir auch noch dazu, wie wir unter Umständen agieren könnten, wenn wir z. B. auf eine „IsLoading“-Eigenschaft eines ViewModels keinen Zugriff haben.

Das könnte z. B. so aussehen:

Public Class LoginCommand
    Implements ICommand

    Private _failedAttempts As Integer

    Public Sub Execute(parameter As Object) Implements ICommand.Execute
        ' simulate failed login attempt
        _failedAttempts += 1
        RaiseEvent CanExecuteChanged(Me, EventArgs.Empty)
    End Sub

    Public Function CanExecute(parameter As Object) As Boolean Implements ICommand.CanExecute
        Return _failedAttempts < 3
    End Function

    Public Event CanExecuteChanged As EventHandler Implements ICommand.CanExecuteChanged

End Class

using System.Windows.Input;
using System;

public class LoginCommand : ICommand
{
    private int _failedAttempts;

    public void Execute(object? parameter)
    {
        // simulate failed login attempt
        _failedAttempts++;
        CanExecuteChanged?.Invoke(this, EventArgs.Empty);
    }

    public bool CanExecute(object? parameter)
    {
        return _failedAttempts < 3;
    }

    public event EventHandler? CanExecuteChanged;

}

Der ganze Aufwand für ein einziges Command?

Ich gebe zu, dass dies alles, vor allem als Anfänger natürlich erstmal überwältigend klingen kann, besonders für bisher ein einziges Command, aber keine Sorge – „I got you“. Statt diesen Aufwand immer wieder von vorn zu betreiben, werden wir uns – als „faule“ Entwickler – selbstverständlich einige Hilfsmittel schreiben, Welche uns die Arbeit vereinfachen. Im ersten Schritt wird das die gleich folgende, wiederverwendbare Klasse Namens z. B. „DelegateCommand“ sein.

Eine wiederverwendbare DelegateCommand-Klasse

Wie Du vermutlich im letzten Schritt festgestellt hast, ist das Ganze mit den WPF Commands nicht so „mal eben“ wie mit den Click-Handlern erledigt. Lasse Dich aber bitte hier dennoch nicht dazu verführen – typisch Mensch, typisch Gewohnheitstier – dennoch wieder die alten „Button1_Click“ und Co. Dinger zu verwenden. Wir können uns wie hier drüber erwähnt, auch viele Hilfsmittel erschaffen, mit Denen wir uns das Handling deutlich vereinfachen können.

Im Endeffekt ändert sich von der Konzeption des Commands selbst, nicht viel, wir brauchen immer noch folgende Aspekte:

1. Was soll bei Ausführung getan werden?
2. Kann es ausgeführt werden?
3. Wann ändert sich die Info, ob’s ausgeführt werden kann?

Allerdings möchten wir nun nicht jedes Mal dafür eine eigene Klasse erstellen, sondern alles ein wenig mehr zentralisieren. Das können wir ganz einfach, indem wir Obiges logisch betrachten: Punkt 1 ist einfach nur ein „Packen“ Arbeit, Welchen wir in die Zukunft delegieren (vielleicht rückt der Begriff „DelegateCommand“ nun etwas näher 😉), nämlich bei z. B. einem Klick. Punkt 2 ist praktisch das Gleiche in bunt, nur, dass wir eine „Ja/Nein“-Info zurückbekommen: Also einen Boolean. Punkt 3 kann je nach Fall komplizierter werden, aber auch das lässt sich regeln.

Methoden / Funktionalität dynamisch übergeben

Wenn man nun zu den obigen Erkenntnissen gekommen ist, fragt man sich im nächsten Schritt das Offensichtliche: „Okay, aber wie verlagere / gruppiere ich denn überhaupt Arbeit?“. Das Stichwort, bzw. die Stichworte Deiner Begierde nennen sich „Action„, bzw. „Func„. Diese übernehmen exakt das, was wir bruachen, Sie kapseln / gruppieren unsere Anweisungen und machen Diese praktisch ansprech- und ausführbar – auch später.

Der erste Versuch – delegierte Arbeit

Schreiben wir also nun unseren aus den Erkenntnissen resultierenden, ersten Versuch. Hierbei geht es erstmal nur darum, die „Was soll getan werden“-Anweisungen als Gruppe von Anweisungen zu verlagern / zu delegieren. Das geht auch im Endeffekt ganz einfach, schaue Dir dazu diese neue Variante unserer Command-Implementierung an.

Wir lassen hierbei der instaziierenden Partei die Möglichkeit, den gruppierten Stapel an Arbeit von außen mitzugeben. Beachte auch, dass wir sogar die Möglichkeit haben, einen Parameter mitzuliefern. Dadurch sind wir – indem wir z. B. eine weitere Klasse erstellen – auch nicht auf einen Übergabeparameter limitiert, könnten also praktisch eine ganze „Config“ mitliefern. Natürlich muss dies passend in der Execute-Methode gecastet werden..

Namespace Utils

    Public Class DelegateCommand
        Implements ICommand

        Private _action As Action(Of Object)

        Sub New(action As Action(Of Object))
            _action = action
        End Sub

        Public Sub Execute(parameter As Object) Implements ICommand.Execute
            ' führt unsere von außen mitgegebene Aktion aus und übergibt auch den Parameter
            _action(parameter)
        End Sub

        Public Function CanExecute(parameter As Object) As Boolean Implements ICommand.CanExecute
            Return True
        End Function

        Public Event CanExecuteChanged As EventHandler Implements ICommand.CanExecuteChanged

    End Class

End Namespace

using System.Windows.Input;
using System;

namespace Utils;

public class DelegateCommand : ICommand
{
    private Action<object?> _action;

    public DelegateCommand(Action<object?> action)
    {
        _action = action;
    }

    public void Execute(object? parameter)
    {
        // führt unsere von außen mitgegebene Aktion aus und übergibt auch den Parameter
        _action?.Invoke(parameter);
    }

    public bool CanExecute(object? parameter)
    {
        return true;
    }

    public event EventHandler? CanExecuteChanged;

}

Delegierte Arbeit im MainViewModel verwenden

Zurück in unserem (komprimierten) MainViewModel, könnte die Erstellung des Commands nun wie gleich folgend und vollkommen dynamisch aussehen. Beachte auch, dass wir durch Polymorphie oben ein „ICommand“ deklarieren, aber ein diese Schnittstelle implementierendes Objekt zuweisen können (im Konstruktor).

Imports WpfCommandsVbTutorial.Utils

Namespace ViewModels

    Public Class MainViewModel
        Inherits PropertyChangedBase

        ' restliche Eigenschaften..

        Public Property LoginCommand As ICommand

        Sub New()
            LoginCommand = New DelegateCommand(AddressOf Login)
        End Sub

        ' unsere gruppierten Anweisungen - zusammengefasst
        Private Sub Login(parameter As Object)
            ' tu dies
            ' tu jenes
            ' tu das
        End Sub

    End Class

End Namespace

using System.Windows.Input;
using Utils;

namespace ViewModels;

public class MainViewModel : PropertyChangedBase
{

    // restliche Eigenschaften..

    public ICommand LoginCommand { get; set; }

    public MainViewModel()
    {
        LoginCommand = new DelegateCommand(Login);
    }

    // unsere gruppierten Anweisungen - zusammengefasst
    private void Login(object? parameter)
    {
        // tu dies
        // tu jenes
        // tu das
    }
}

Was fehlt ist, ob’s geht!

Was nun noch als vorletzter Punkt fehlt, ist eine dynamische Feststellung, ob das Command überhaupt ausgeführt werden kann, denn das haben wir aktuell völlig vernachlässigt. Zum Glück können wir uns auch hier ganz schnell helfen, denn dafür gab es neben der „Action“ auch etwas namens „Func“. Damit können wir eine Funktion dynamisch übergeben und dessen Rückgabewert nach unserem Belieben auswerten.

Hierzu habe ich einen neuen Konstruktor erstellt, Welcher uns dann die optionale Möglichkeit bietet, sagen zu können: „Hey, so stellst Du fest, ob das Command ausgeführt werden kann“. Wenn dies also nicht mitgegeben wird, könnte man praktisch davon ausgehen, dass das Command immer ausgeführt werden kann.

Die finale DelegateCommand-Basisklasse

Namespace Utils

    Public Class DelegateCommand
        Implements ICommand

        Private _action As Action(Of Object)

        Private _canExecute As Func(Of Object, Boolean)

        Sub New(action As Action(Of Object))
            _action = action
        End Sub

        Sub New(action As Action(Of Object), canExecute As Func(Of Object, Boolean))
            _action = action
            _canExecute = canExecute
        End Sub

        Public Sub Execute(parameter As Object) Implements ICommand.Execute
            ' führt unsere von außen mitgegebene Aktion aus und übergibt auch den Parameter
            _action(parameter)
        End Sub

        Public Function CanExecute(parameter As Object) As Boolean Implements ICommand.CanExecute
            If _canExecute Is Nothing Then
                Return True
            End If
            Return _canExecute(parameter)
        End Function

        Public Event CanExecuteChanged As EventHandler Implements ICommand.CanExecuteChanged

    End Class

End Namespace

using System.Windows.Input;
using System;

namespace Utils
{
    public class DelegateCommand : ICommand
    {
        private Action<object?> _action;

        private Func<object?, bool>? _canExecute;

        public DelegateCommand(Action<object?> action)
        {
            _action = action;
        }

        public DelegateCommand(Action<object?> action, Func<object?, bool> canExecute)
        {
            _action = action;
            _canExecute = canExecute;
        }

        public void Execute(object? parameter)
        {
            _action(parameter);
        }

        public bool CanExecute(object? parameter)
        {
            if (_canExecute == null)
                return true;
            return _canExecute(parameter);
        }

        public void RaiseCanExecuteChanged()
        {
            CanExecuteChanged?.Invoke(this, EventArgs.Empty);
        }

        public event EventHandler? CanExecuteChanged;
    }
}

Nun kann unser MainViewModel wie folgt ergänzt werden:

Imports WpfCommandsVbTutorial.Utils

Namespace ViewModels

    Public Class MainViewModel
        Inherits PropertyChangedBase

        ' other properties..

        Private Property LoginAttempts As Integer

        Public Property LoginCommand As ICommand

        Sub New()
            LoginCommand = New DelegateCommand(AddressOf Login, AddressOf CanLogin)
        End Sub

        ' our grouped instructions - summed up
        Private Sub Login(parameter As Object)
            ' do this
            ' do that
            ' do something else
            LoginAttempts += 1
        End Sub

        Private Function CanLogin(parameter As Object) As Boolean
            ' determine, if the login process should be executed and return it
            Return LoginAttempts < 3
        End Function

    End Class

End Namespace

using System.Windows.Input;
using Utils;

namespace ViewModels;

public class MainViewModel : PropertyChangedBase
{

    // restliche Eigenschaften..

    private int LoginAttempts { get; set; }

    public ICommand LoginCommand { get; set; }

    public MainViewModel()
    {
        LoginCommand = new DelegateCommand(Login, CanLogin);
    }
    
    // our grouped instructions - summed up
    private void Login(object? parameter)
    {
        // do this
        // do that
        // do something else
        LoginAttempts++;
    }

    private bool CanLogin(object? parameter)
    {
        // determine, if the login process should be executed and return it
        return LoginAttempts < 3;
    }
}

Und was, wenn es sich ändert?

Nun kommen wir (sorry, endlich) zum finalen Punkt: Wir müssen auch hier die Möglichkeit bieten, sagen zu können: „Hey Oberfläche, bitte neu evaluieren, ob das Command ausgeführt werden kann“. Dafür gibt es z. B. die „CommandManager.InvalidateRequerySuggested“-Methode, Welche ich aber nicht ganz toll finde. Alle Commands re-evaluieren, nur weil sich ggf. Eines geändert hat? Nee..

Wir werden stattdessen unser eigenes kleines Helferlein dafür einbauen, ich meine, dafür haben wir ja sowieso schon unsere Basisklasse. Wir ergänzen also eine Methode, Welche es uns von außen erlaubt, das „CanExecuteChanged“-Ereignis des Commands auszulösen. Für mich fühlt sich auch das nicht ganz super an, aber es deckt genau unsere Bedürfnisse:

Namespace Utils

    Public Class DelegateCommand
        Implements ICommand

        Private _action As Action(Of Object)

        Private _canExecute As Func(Of Object, Boolean)

        Sub New(action As Action(Of Object))
            _action = action
        End Sub

        Sub New(action As Action(Of Object), canExecute As Func(Of Object, Boolean))
            _action = action
            _canExecute = canExecute
        End Sub

        Public Sub Execute(parameter As Object) Implements ICommand.Execute
            _action(parameter)
        End Sub

        Public Function CanExecute(parameter As Object) As Boolean Implements ICommand.CanExecute
            If _canExecute Is Nothing Then
                Return True
            End If
            Return _canExecute(parameter)
        End Function

        Public Sub RaiseCanExecuteChanged()
            RaiseEvent CanExecuteChanged(Me, EventArgs.Empty)
        End Sub

        Public Event CanExecuteChanged As EventHandler Implements ICommand.CanExecuteChanged

    End Class

End Namespace

using System.Windows.Input;
using System;

namespace Utils;

public class DelegateCommand : ICommand
{
    private Action<object?> _action;

    private Func<object?, bool>? _canExecute;

    public DelegateCommand(Action<object?> action)
    {
        _action = action;
    }

    public DelegateCommand(Action<object?> action, Func<object?, bool>? canExecute)
    {
        _action = action;
        _canExecute = canExecute;
    }

    public void Execute(object? parameter)
    {
        _action(parameter);
    }

    public bool CanExecute(object? parameter)
    {
        if (_canExecute == null)
            return true;
        return _canExecute(parameter);
    }

    public void RaiseCanExecuteChanged()
    {
        CanExecuteChanged?.Invoke(this, EventArgs.Empty);
    }

    public event EventHandler? CanExecuteChanged;
}

Zum Schluss nun unsere letzte MainViewModel-Anpassung (bezogen auf die fehlgeschlagene Logins Geschichte):

Imports WpfCommandsVbTutorial.Utils

Namespace ViewModels

    Public Class MainViewModel
        Inherits PropertyChangedBase

        ' restliche Eigenschaften

        Public Property LoginCommand As CommandBase

        Private _loginAttempts As Integer

        Private Property LoginAttempts As Integer
            Get
                Return _loginAttempts
            End Get
            Set(value As Integer)
                _loginAttempts = value
                LoginCommand.RaiseCanExecuteChanged()
            End Set
        End Property

        Sub New()
            LoginCommand = New CommandBase(AddressOf Login, AddressOf CanLogin)
        End Sub

        Private Sub Login(parameter As Object)
            ' fehlgeschlagenen Login simulieren..
            LoginAttempts += 1
        End Sub

        Private Function CanLogin(parameter As Object) As Boolean
            Return _loginAttempts < 3
        End Function

    End Class

End Namespace

using Utils;

namespace ViewModels;

public class MainViewModel : PropertyChangedBase
{

    // restliche Eigenschaften

    public DelegateCommand LoginCommand { get; set; }

    private int _loginAttempts;

    private int LoginAttempts
    {
        get => _loginAttempts;
        set
        {
            _loginAttempts = value;
            LoginCommand.RaiseCanExecuteChanged();
        }
    }

    public MainViewModel()
    {
        LoginCommand = new DelegateCommand(Login, CanLogin);
    }

    private void Login(object? parameter)
    {
        // simulate failed login
        LoginAttempts++;
    }

    private bool CanLogin(object? parameter)
    {
        return _loginAttempts < 3;
    }
}

Wie übergibt man Command-Parameter?

Bisher konnten wir schon viele Eindrücke in das WPF Command gewinnen, eine Sache ist jedoch noch ein wenig auf der Strecke geblieben, sorry. Es geht um das Übergeben von Parametern, da wir ja auch z. B. extra eine „Action“ / „Func“ mit generischem Typenparameter vom Typ „Object“ deklariert haben. Bisher verwenden wir diese Möglichkeit der Parameterübergabe noch nicht.

💡 Hinweis: Viele Online-Code-Schnipsel verwenden die Übergabe des Parameters auch als Möglichkeit, die PasswordBox in das Command zu übergeben und so das Passwort bei Bedarf abzurufen. Es ist laut Diskussion im Netz zwar in erster Linie „sicherer“ und sicherlich eine mögliche Herangehensweise, allerdings finde ich dies wenig praktikabel.

Jeder (und ich meine jeder) Entwickler muss hier selbst entscheiden, Welche Sicherheitsmaßnahmen für sich, Kunden und Co. angemessen sind! Dies soll die „Considerations“ selbstverständlich trotzdem nicht kleinreden und man sollte sich an „best practices“ halten..

Warum, bzw. wann übergibt man Command-Parameter?

Bevor man sich allerdings tiefer in diesen Dschungel wagt, macht diese kleine Überlegung ggf. auch Sinn: „Wann braucht man Command-Parameter überhaupt!?“. Grundsätzlich können wir ja auf die Eigenschaften unseres Viewmodels zugreifen, wenn wir lokale Methoden des ViewModels mit der DelegateCommand-Klasse von oben verwenden. Das stimmt soweit auch, aber wie wir schon im Absatz hier drüber gesehen haben, kann es Situationen geben, wo wir auf die Dinge ggf. keinen Zugriff haben, dann könnte so eine Übergabe helfen.

Parameter manuell via XAML übergeben

Lasse uns daher einmal im nächsten Schritt schauen, wie wir diese Möglichkeit der Parameter nun allgemein verwenden könnten. Ich denke hier zuerst an die einfachste Variante, also eine einfache „manuelle“ Übergabe. Dies können wir sehr einfach im XAML-Code erledigen, indem wir einfach einen passenden Wert, an die „CommandParameter“-Eigenschaft mitliefern:

<Button Command="{Binding LoginCommand}" CommandParameter="D" />

WPF Command-Parameter via DataBinding übergeben

Auch ganz interessant ist die eigentlich offensichtlichste Sache, also die Übergabe via normalem Databinding. Hierzu kann ich einfach eine normale „Binding-Expression“, also einen Bindungs-Ausdruck schreiben. Dieser wird dann zu passender Zeit evaluiert und als CommandParameter übergeben:

<Button Command="{Binding LoginCommand}" CommandParameter="{Binding SomeBoundPropertyToPassIn}" />

Mehrere Parameter via Klasse oder MultiBinding übergeben

Hier kommt noch ein wichtiger Punkt, da viele Anfänger daran scheitern. Häufig stellt man folgende Überlegung an: „Okay, so übergebe ich einen einzigen Parameter an das WPF Command, aber wie kann ich Mehrere auf einmal übergeben?“.

Aber keine Sorge, die Antwort ist relativ einfach, die erste Variante wäre via eigener Klasse. Lege dazu einfach eine passende Klasse mit den Eigenschaften / Werten, die Du übertragen möchtest, an:

Public Class SpecialCmdParams

    Public Property SomePropToPassOne As String

    Public Property SomePropToPassTwo As Integer

    ' ...

End Class

public class SpecialCmdParams
{

    public string SomePropToPassOne { get; set; }

    public int SomePropToPassTwo { get; set; }

    // ...

}

Instanziiere diese Klasse nun an passender Stelle, z. B. im ViewModel-Konstruktor und befülle die Eigenschaften durch passende Bindungen an z. B. Textboxen, whatever. Im nächsten Schritt kannst Du die Instanz der Klasse natürlich einfach via Datebindung (wie hier drüber, siehe „SomeBoundPropertyToPassIn“) übergeben. Gleich schauen wir uns noch an, wie man dies dann abrufen kann.

Parameter via Multibinding übergeben

Wer keine Lust hat jedes Mal eine passende Klasse zu erstellen, kann sich die Übergabe mehrerer Command-Parameter auch durch ein sogenanntes „Multibinding“ vereinfachen. Wie der Name schon sagt, bindet man hier nicht an ein „Ding“, sondern kann gleich mehrere Datenbindungen quasi in Einer verwenden.

Das Blöde ist hier nur, dass man einen „Converter“ benötigt, wie soll sonst aus „mehrere Dinger“ -> „ein Ding“ werden? Man muss hier auch noch bedenken, dass man eventuell den Weg zurück braucht, also aus einem Ding wieder Mehrere zu machen. Ein derartiges, passendes Muster finden wir bei der „IMultiValueConverter“-Schnittstelle.

Implementieren wir dieses Interface also einmal beispielhaft, um mehrere Zahlen zu übergeben (auch wenn dies bei einem Login keinen Sinn macht), es geht wie gesagt um „Commands“ selbst :)! Wir übergeben hier einfach mal stumpf die Größe des Login-Fensters. Dies könnten wir natürlich auch durch eine normale Datenbindung realisieren, aber es geht wie gesagt um ein Beispiel!

Beachte, dass die Implementierung hier nur beispielhaft und z. B. nicht konfigurierbar ist. Zum Thema „ValueConverter“ im Allgemeinen werde ich ggf. noch einen separaten Beitrag schreiben. Erstelle also nun einmal folgende Klasse, im (z. B.) „Utils“-Ordner

Imports System.Globalization

Namespace Utils

    Public Class DoubleNumberConverter
        Implements IMultiValueConverter

        Public Function Convert(values() As Object, targetType As Type, parameter As Object, culture As CultureInfo) As Object Implements IMultiValueConverter.Convert
            Return String.Join("|", values)
        End Function

        Public Function ConvertBack(value As Object, targetTypes() As Type, parameter As Object, culture As CultureInfo) As Object() Implements IMultiValueConverter.ConvertBack
            Return value.ToString.Split("|")
        End Function

    End Class

End Namespace

using System.Globalization;

namespace Utils
{
    public class DoubleNumberConverter : IMultiValueConverter
    {
        public object Convert(object[] values, Type targetType, object parameter, CultureInfo culture)
        {
            return string.Join("|", values);
        }

        public object[] ConvertBack(object value, Type[] targetTypes, object parameter, CultureInfo culture)
        {
            return value.ToString().Split("|");
        }
    }
}

Damit können wir dann ein Multibinding realisieren, Welches dann über übliche Binding-Ausdrücke Daten mitliefert – aber eben Mehrere! Vergiss hier jedoch nicht, eine Instanz des „DoubleNumberConverters“ entweder in der App.xaml / Application.xaml, oder in Deinem jeweiligen Control (UserControl, Window, etc..) zu erstellen. Ansonsten kannst Du den Konverter nicht verwenden:

<!-- The Window here is named "MyWindow" for example purposes -->

    <!-- further above -->
    <Window.Resources>
        <ResourceDictionary>
            <u:DoubleNumberConverter x:Key="MyDoubleNumberConverter" />
        </ResourceDictionary>
    </Window.Resources>

<!-- usage -->
<Button Command="{Binding LoginCommand">
    <Button.CommandParameter>
        <MultiBinding Converter="{StaticResource MyDoubleNumberConverter}">
             <Binding Path="ActualWidth" ElementName="MyWindow"/>
             <Binding Path="ActualHeight" ElementName="MyWindow"/>
        </MultiBinding>
    </Button.CommandParameter>
</Button>

Übergebene Parameter abgreifen

Nachdem wir die Beispiele zum Übergeben der Parameter gesehen haben, schauen wir uns nun an, wie wir Diese auch wieder abgreifen können. Je nachdem Welches der obigen Beispiele Du verwendest, sieht die Vorgehensweise eigentlich immer gleich aus (auch bei CanExecute):

' rest of the ViewModel-Class (like MainViewModel)

' the "parameter" contains everything, but combined in one thing
Public Sub Login(parameter As Object)
    ' if it looked like this in the XAML:
    ' CommandParameter="D"
    Dim passedLetter = Convert.ToString(parameter)
    ' now there's the letter D inside passedLetter

    '' if it was a custom class
    Dim yourParam = CType(parameter, SpecialCmdParams)

    '' if it was the DoubleNumberConverter - you now have :
    Dim numbersAsStrings = Convert.ToString(parameter).Split("|")
    ' do conversion, whatever
End Sub

' rest of the ViewModel-Class

public void Login(object parameter)
{
    // if it looked like this in the XAML:
    // CommandParameter="D"
    var passedLetter = Convert.ToString(parameter);
    // now there's the letter D inside passedLetter

    // // if it was a custom class
    var yourParam = (SpecialCmdParams)parameter;

    // // if it was the DoubleNumberConverter - you now have :
    var numbersAsStrings = Convert.ToString(parameter).Split("|");
}

Downloads

Lade Dir hier gerne das Beispielprojekt (oder einzelne Bestandteile) in der Sprache Deiner Wahl herunter, da der Beitrag natürlich anhand des Themas ein wenig riesig ist. So kannst Du Dich spielerisch an die einzelnen Punkte wagen und begleitend mit dem Beitrag arbeiten. Die einzelnen Dinge beinhalten jeweils die Dateien für beide Sprachen.

Der Beitrag Eigene WPF Commands in MVVM VB.NET & C# – der 2024 Guide erschien zuerst auf Robert Skibbe.

Moderne Software durch WPF MVVM Projekte erstellen

In diesem Guide zeige ich, wie du ein WPF MVVM Projekt aufsetzen kannst — Schritt für Schritt, von der Ordnerstruktur bis zur wiederverwendbaren Projektvorlage.

Falls du von WinForms umsteigst, lies auch: Windows Forms zu WPF migrieren – Der vollständige Guide

Viele mich anschreibende Zuschauer und Kunden haben sich gewünscht, dass ich mal einen Projektaufbau nach Model-View-ViewModel-Manier zeige – von Beginn an und ohne anderes Zeug. Also hier kommt er nun, der Beitrag, wie man ein VB.NET, bzw. ein C# WPF Projekt anhand der MVVM-Struktur aufsetzt und durch ein Projekttemplate sogar wiederverwendbar macht.

In erster Linie sind hier die Ordnerstruktur, die Konfiguration des Start-Prozesses und einige kleine / weitere Dinge relevant, aber genug gequasselt – let’s go 🤓!

Kurzfassung – WPF MVVM Projekt aufsetzen

Grundsätzlich kann man die Schritte wie folgt zusammenfassen, allerdings ist dies natürlich nur extrem kukrz gefasst und Bedarf sicherlich einer genaueren Beschreibung. Diese findest Du selbstverständlich weiter unten, wenn Dir die groben Schritte nicht ausreichen sollten – wovon ich ausgehe, da Diese nur einer Art Leitfaden darstellen.

Die Schritte wären an sich wie folgt:

• Erstelle die MVVM-typischen Ordner: Views, ViewModels, Models, Utils (optional)
• Verschiebe das MainWindow über den Visual Studio Projektmappenexplorer in den „Views„-Ordner
• Passe den Namen des MainWindows zu „MainView“ an
• Sorge dafür, dass das MainView in einem passenden Namespace ist – Achtung: Code behind Datei, sowie auch die XAML-Datei
• Setze im MainView einen DataContext (entweder im XAML oder Code behind)
• Passe die StartupUri in Deiner Application.xaml Datei an: „Views/MainView.xaml“
• Implementiere die INotifyPropertyChanged-Schnittstelle in einer Basisklasse – für die Vererbung an ViewModel-Klassen (in den Utils-Ordner damit)
• Erstelle eine passende MainViewModel–Klasse, Welche von Deiner „PropertyChanged“-Implementierung erbt (häufig auch ShellViewModel genannt)

💡 Hinweis: Nutze gerne das Inhaltsverzeichnis, wenn Du es eilig hast und einfach drauf los coden möchtest. Ich würde Dir allerdings empfehlen, auch die Details hinter dem Ganzen zu verstehen und ggf. ein wenig mehr Zeit zu investieren.

INotifyPropertyChanged in WPF — Warum und wie

Beachte, dass ich nicht genauer auf das „INotifyPropertyChanged“-Interface eingehen werden, dies habe ich im Beitrag „Der ultimative INotifyPropertyChanged Guide“ getan. Klicke auf den Link, falls Du die Basisklasse oder auch detaillierte Informationen zum Thema benötigst – der Link schickt Dich direkt zur Basisklasse.

Kurzgesagt ist diese Schnittstelle eine Art Vertrag (eine Schnittstelle eben..), damit die „WPF-Engine“ – so nenne ich Sie jetzt einfach mal – weiß: „Hey, wann und wie werden mir Änderungen kommuniziert?“. Es ist daher unsere Aufgabe als Entwickler, Sie korrekt zu implementieren und an den notwendigen Stellen das „PropertyChanged“-Ereignis auszulösen. Somit weiß die Oberfläche dann: „Aha, da ist was passiert, also muss ich aktiv werden“.

Mehr über das MVVM-Entwurfsmuster selbst

Das MVVM Pattern in WPF ist der Standard für saubere, testbare Desktop-Anwendungen.

Falls Du eventuell völlig neu im Themenbereich MVVM bist, kann ich Dir hier auch meinen Beitrag über das „Model-View-ViewModel-Entwurfsmuster“ empfehlen. Lass Dich hier bitte nicht von der „Spezialisierung“ auf C# verwirren, letztendlich ist hier alles analog und die Erkenntnisse helfen Dir in beiden .NET-Sprachen gleichermaßen.

Schritt 1: MVVM-Ordner anlegen

Wenn Du noch keine passenden Ordner für die üblichen MVVM-Bestandteile erstellt hast, machen wir dies nun zuerst. Verwende dafür die Werkzeuge aus Visual Studio, damit die Ordner auch von Visual Studio selbst korrekt erfasst werden. Führe dazu einfach z. B. einen Rechtsklick auf Deine Projektmappe (nicht auf die Lösung / Solution) aus und wähle „Hinzufügen->Ordner“.

Erstelle nun innerhalb Deiner Projektmappe unter anderem einen Ordner namens „ViewModels„, hier kommen – wie der Name schon sagt – unsere ViewModels rein. Füge dann bitte noch einen weiteren Ordner namens „Views“ hinzu, dort werden wir die grafischen Gegenstücke – also unsere visuellen Bedien-Oberflächen – zu unseren ViewModels ablegen. Dazu könnten übrigens auch kleinere Komponenten, wie z. B. eine Navigationsleiste gehören (ergo NavigationBarView).

Die richtige WPF Projektstruktur — Ordner und Namespaces

Achtung: Wenn Du MVVM-Hilfs-Frameworks wie „Caliburn Micro“ verwendest, könntest Du allerdings ein wenig an Namenskonventionen gebunden sein. Hierüber jedoch auch noch zu berichten, würde bekanntlich den Rahmen des Beitrages sprengen, schätze ich. Verlasse Dich daher am Anfang auf die in diesem Beitrag angepeilte Routine.

Im letzten Schritt benötigen wir noch einen weiteren kleinen „Hilfs-Ordner„, dort packen wir nützliche Helferlein rein, Welche uns den Alltag in MVVM versüßen. Nenne den Ordner daher einfach „Utils“ (Utilities/Hilfsmittel), später kommt dort dann die wiederverwendbare „PropertyChangedBase“-Klasse hinein. Wenn Du auch den Beitrag zur „INotifyPropertyChanged“-Schnittstelle besucht hast, hast Du hier auch schon die notwendige „PropertyChangedBase“-Basisklasse drin. Besuche ansonsten einfach den Link, ziehe Dir den Code (wo Du direkt auskommen solltest) und packe die Klasse in den „Utils“-Ordner.

Unsere finale Struktur sollte also nun wie folgt aussehen:

💡 Hinweis: Wir werden in diesem Beitrag die „PropertyChangedBase“-Basisklasse aus meinem Beitrag zum Thema „Die INotifyPropertyChanged-Schnittstelle – Änderungen kommunizieren“ verwenden. Stelle sicher, dass Du die Klasse also im „Utils“-Ordner und dem passenden Namespace ablegst! Klicke einfach auf den Link und Du kommst sofort zur passenden Klasse im Beitrag (VB.NET & C# Code).

Schritt 2: MainWindow verschieben & umbenennen

Im folgenden Schritt müssen wir auch noch daran denken, das „MainWindow“ MVVM-gemäß umzubenennen und zu verschieben. Dies führt natürlich aufgrund der Standard-Konfiguration des Projektes zu Fehlern. Weder weiß die „Application.xaml“-Datei nach dem Umzug, wo unser Hauptfenster ist, noch, dass es nicht mehr im Root-Namespace ist (im Namensraum unseres Projektes).

Ab in den richtigen Ordner

Schiebe das MainWindow nun in den Ordner namens „Views“, verwende dazu am besten den Drag & Drop-Vorgang im Visual Studio selbst. Wenn Du dies außerhalb machst, kann es zu Problemen führen, da Visual Studio es ggf. nicht korrekt erkennt. Nun befindet sich unsere grafische Oberfläche (potenziell Eine von Vielen) im richtigen Ordner, allerdings fehlt noch was.

Einen MVVM entsprechenden Namen & Namespace

Benenne im nächsten Schritt das „MainWindow“ in „MainView“ um und achte darauf, dass dies auch anschließend korrekt in der ersten Zeile des XAML-Codes widergespiegelt wird. Verwende dazu einfach die F2-Taste, während Du Dein MainWindow im Projektmappen-Explorer ausgewählt (und den Fokus darauf) hast. Passe – wie hier drunter dargestellt – auch gleich den Namespace an, also schreibe das „Views.“-Prefix vor die eigentliche Bezeichnung.

DataContext in WPF setzen — via XAML oder Code-Behind

Beachte hier, dass Du diese beiden Zeilen (mit x:Class & xmlns:vm) separat in Dein Projekt kopierst / Sie abänderst, sonst zerstörst Du ggf. Dein bestehendes Projekt. Dort stehen ja auch noch andere Dinge, wie z. B. die Fenstergröße, usw. Diese habe ich hier bewusst ausgelassen! Den ViewModels Namespace kannst Du aktuell außer acht lassen, bzw. als Fehler drin lassen – darum kümmern wir uns später. Durch die später erstellte Klasse wird der Namespace hier verfügbar – ggf. musst Du hierfür einmal das Projekt debuggen/builder, damit „er“ es kapiert.

Dann setzen wir noch im letzten Schritt den Fenster-Datenkontext via XAML, wir erstellen also eine Instanz der MainViewModel-Klasse via XAML-Code. Dies könntest Du auch – wie gleich angemerkt – via „Code behind“-Datei durchführen.

<Window x:Class="Views.MainView"
        xmlns:vm="clr-namespace:WpfCommandsVbTutorial.ViewModels">

    <Window.DataContext>
        <vm:MainViewModel />
    </Window.DataContext>

    <!-- restlicher XAML-Code -->
</Window>

Diese Änderungen werden wir nun auch im sogenannten „Code behind“-File übernehmen / sicherstellen. Gehe dazu einfach in diese Datei, indem Du die F7-Taste drückst, während Du Dich im XAML-Designer des MainViews (ehemals MainWindows) befindest. Danach springt die Visual Studio IDE via Hotkey in die „Code behind“-Datei und Du solltest folgenden Code einfügen – also das MainView mit einem Namespace umgeben.

Anmerkung zum DataContext

Optional könntest Du die DataContext-Eigenschaft hier festlegen, wir werden dies allerdings im XAML-Code machen, daher entfällt es hier weg, bzw. ist es hier optional. Es geht also an dieser Stelle hier erstmal um den Namespace und die Klasse selbst, sieh‘ Dir aber auch gern an, wie Du auch hier den Datenkontext festlegen könntest.

Mach‘ Dir hier übrigens keine Sorgen über das „MainViewModel“, dabei handelt es sich um eine Klasse, Welche wir gleich noch erstellen werden!

Namespace Views

    Class MainView
        
        '' entfällt durch View-seitige DataContext-Konfiguration
        'Sub New()
            'InitializeComponent()
            '' Import bei Bedarf nicht vergessen!!
            'DataContext = New MainViewModel()
        'End Sub

    End Class

End Namespace

namespace Views
{
    class MainView
    {

        //// entfällt durch View-seitige DataContext-Konfiguration
        //public MainView()
        //{
            //InitializeComponent();
            //// Import bei Bedarf nicht vergessen!!
            //DataContext = new MainViewModel();
        //}

    }
}

Schritt 3: Start-Prozess der Software anpassen (Bootstrapping)

Nun müssen wir ein wenig Feintuning betreiben, da das Programm nach unseren Änderungen mehr oder weniger ins Leere laufen würde. Das liegt daran, dass wir das MainWindow erstens umbenannt und zweitens verschoben haben (und denke an die Namespace-Änderung). Nun muss die Zeile mit der „StartupUri“ in der „Application.xaml / App.xaml“-Datei angepasst werden.

Achte bitte darauf, dass ich mein Projekt „WpfCommandsVbTutorial“ genannt hatte und Du dies durch Deinen eigenen Projektnamen ersetzen musst. Dadurch gibst Du praktisch Bescheid: „Hey, hier ist nun das Start-Fenster/View, um die Anwendung zu starten“.

<Application x:Class="Application"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:local="clr-namespace:WpfCommandsVbTutorial"
             StartupUri="Views/MainView.xaml">
    <Application.Resources>
         
    </Application.Resources>
</Application>

Schritt 4: ViewModel in WPF erstellen — Basisklasse und MainViewModel

Im nächsten und letzten Schritt müssen wir für das oben konfigurierte View nun ein passendes ViewModel erstellen. Das View ist ja wie Du vermutlich weißt (oder gelernt hast) das grafische Gegenstück (ohne Geschäftslogik) zum View. Es mag also im wahrsten Sinne des Wortes „cool“ aussehen, aber letztendlich nichts „können“.

Eine wiederverwendbare Basisklasse

Um uns nicht immer wiederholen zu müssen, machen wir hier Gebrauch von der schon mehrfach erwähnten „PropertyChangedBase“-Basisklasse aus meinem anderen Beitrag. Gehe daher also bitte hin und erstelle diese Klassen-Datei im oben angelegten „Utils“-Ordner. Einen detaillierten Guide findest Du dazu im oben verlinkten Beitrag.

Imports System.ComponentModel
Imports System.Runtime.CompilerServices
Namespace Utils
    Public MustInherit Class PropertyChangedBase
        Implements INotifyPropertyChanged
        Protected Sub NotifyOfPropertyChange(<CallerMemberName> Optional propertyName As String = Nothing)
            RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(propertyName))
        End Sub
        Public Event PropertyChanged As PropertyChangedEventHandler Implements INotifyPropertyChanged.PropertyChanged
    End Class
End Namespace

using System.Runtime.CompilerServices;
using System.ComponentModel;
namespace Utils;
public abstract class PropertyChangedBase : INotifyPropertyChanged
{
    protected void NotifyOfPropertyChange([CallerMemberName] string? propertyName = null)
    {
        PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
    }
    public event PropertyChangedEventHandler PropertyChanged;
}

Das MainViewModel

Nun erstellen wir unser MainViewModel, Welches die aufbereiteten Elemente für das View beinhaltet – darunter auch passende Logik, wie z. B. für einen „Button1_Click“. Warum diese typische Ereignishandler aus Winforms (Windows Forms) Zeiten schon lange nicht mehr modern ist und nicht ins MVVM-Entwurfsmuster passt, erfährst Du in einem passenden, baldigen Beitrag.

Da wir dieses beispielhaft aufgesetzte Projekt hier wie initial erwähnt gleich noch als Projektvorlage anlegen möchten, werde ich hier auch keine großen Eigenschaften realisieren. Das MainViewModel bleibt daher also eher karg und leer. Achte auch hier bitte wieder daran, dass Du oben den korrekten Projektnamen für Deine Anwendung verwendest:

Imports WpfCommandsVbTutorial.Utils

Namespace ViewModels

    Public Class NewMainViewModel
        Inherits PropertyChangedBase

        Sub New()
            
        End Sub

    End Class

End Namespace

using WpfCommandsVbTutorial.Utils;

namespace ViewModels
{

    public class NewMainViewModel : PropertyChangedBase
    {

        public NewMainViewModel()
        {
            
        }

    }

}

Bonus: WPF MVVM Projektvorlage erstellen

Als kleines – wie sagt man so schön – Schmankerl, erstellen wir uns aus der gemachten Arbeit nun eine Projektvorlage. Wir möchten ja schließlich vermeiden, diesen ganzen Aufwand für jedes einzelne MVVM-Projekt zu betreiben. Im Endeffekt geht dies nach getaner Arbeit sehr einfach und schnell, mit Hilfe der Visual Studio IDE.

Wenn nun alles nach Deinen Vorstellungen ist, gehe oben im Visual Studio Menü auf „Projekt->Vorlage exportieren“. Dann zeigt sich folgender Dialog und Du kannst ein paar weitere Einstellungen treffen. Wähle im ersten Schritt allerdings einfach nur „Projektvorlage“ – das ist schließlich, was wir wollen, right!?

Wenn Du auf weiter geklickt hast, kommt jetzt der nächste Schritt. Dort kannst Du wohl die beiden essenziellsten Informationen festlegen: Den Namen & die Beschreibung für das Template – wähle hier daher vor allem einen sinnvollen Namen, wie: „<C#> / <VB.NET> MVVM Projekttemplate“, je nachdem für welche Sprache Du Dich ggf. entscheidest. Lege Dir doch auch alternativ für beide Sprachen ein entsprechendes Template an?

💡 Hinweis: Hake hier am besten das Kästchen „Vorlage automatisch in Visual Studio importieren“ an, dann brauchst Du Dich darum nicht manuell kümmern.

Wenn Du nun ein neues Projekt anlegst, findest Du Dein Template ganz einfach wieder:

Der Beitrag Ein WPF MVVM Projekt aufsetzen (VB.NET & C#) – 2026 Guide erschien zuerst auf Robert Skibbe.

Daten im MVVM tabellarisch darstellen – mit WPF DataGrid

Ich glaube jeder Entwickler wird regelmäßig eine Art Tabellen-Steuerelement, also z. B. das WPF DataGrid benutzen müssen. Unter Windows Forms hieß es damals noch „DataGridView“, aber letztendlich hat sich vom offensichtlichen Zweck nichts geändert: Wir möchten dem Nutzer Daten anhand einer Tabellenstruktur darstellen. Diese Daten werden anhand von Reihen, Welche aus verschiedenen Spalten bestehen gegliedert dargestellt.

Daher beschäftigen wir uns im heutigen Beitrag damit, was sich seit den Windows Forms (DataGridView) geändert hat und wie man im heutigen MVVM- (Model-View-Viewmodel-) Entwurfsmuster mit Tabellen arbeitet. Auch wenn wir hier natürlich nicht zu tief in die Details von MVVM selbst abtauchen können, werde ich einen Teil wiederholen.

Gerne kannst Du in meinem Beitrag über das Model-View-ViewModel-Entwurfsmuster mehr Details erfahren. Hierbei spielt es auch keine Rolle, ob man VB.NET oder C# verwendet, denn die Prinzipien sind die Gleichen! Für diesen Beitrag ist auch das Verständnis über die „INotifyPropertyChanged“-Schnittstelle essenziell, also schau auch einmal dort vorbei!

💡 Hinweis: Beachte bitte, dass es nicht „den einen Weg“ gibt. Im heutigen Beitrag schauen wir uns eine Möglichkeit an, alles mehr oder weniger selfmade zu machen, da ich das Grundverständnis wichtig finde. In einem zukünftigen Beitrag, bzw. in einem Update für diesen Beitrag, werde ich dann noch auf die Möglichkeiten mit einem Werkzeug wie Caliburn Micro eingehen. Derartige Frameworks helfen uns Entwicklern bei der Umsetzung und sparen uns Einiges an Arbeit.

Im Videoformat ansehen

Falls Du keine Lust auf Text hast, kannst Du Dir auch gerne mein passendes Video ansehen. Ich würde Dir jedoch trotzdem empfehlen, den ein oder anderen Blick auf diesen Beitrag hier zu werfen, da ich hier noch mehr im Detail auf das Thema eingehen kann.

Ordnerstruktur vorbereiten

Die meisten Entwickler lieben es, alles sauber zu strukturieren, es gehört ja auch irgendwie zum Beruf, oder? Daher gehen wir im nächsten Schritt hin und beginnen mit unserer Projekt-Strukturierung. Achte darauf, dass Du die Ordner nicht aus Versehen in der Projektmappe, sondern tatsächlich im Projektordner erstellst!

Erstelle dazu im ersten Schritt den wichtigsten Ordner in Deinem Projekt, namens „ViewModels“. Danach kannst Du noch den Ordner „Models“ und einen Weiteren namens „Utils“ erstellen. Danach sind wir startklar und können passende ViewModels dort ablegen und darauf zugreifen. Deine Struktur sollte zu diesem Zeitpunkt wie folgt aussehen:

💡 Hinweis: Beachte hier, dass wir uns nicht an alles halten, sprich, wir werden keinen „Views“-Ordner anlegen, da hier die Verwendung des DataGrids im Vordergrund steht! Ich möchte Dich hier nicht unnötig damit verwirren, wie man dann das MainWindow inkl. der Application-Datei auch noch umgestalten müsste, etc.

Allerdings ist dies auch nicht schlimm, da es praktisch im Kern darum geht, wo man die Daten her bekommt und wie man Sie anschließend durch Datenbindungen darstellt.

Das MainViewModel für die WPF DataGrid Bindung

Damit wir gleich irgendwann mit sogenannten Datenbindungen im WPF-Bereich arbeiten können, müssen wir vorerst noch andere Vorbereitungen treffen. Da im MVVM-Entwurfsmuster mit ViewModels und dazugehörigen Views gearbeitet wird, legen wir im nächsten Schritt unser erstes ViewModel an.

Dies wird praktisch das „Haupt-Ding“ unserer Anwendung, daher nennen wir es passenderweise auch „MainViewModel“. Weil wir natürlich sauber arbeiten, achte bitte darauf, dass Du die Klassen-Datei nicht nur im korrekten Ordner (ViewModels) anlegst, sondern auch mit einem korrekten Namespace versiehst!

💡 Hinweis: Für das C#-Snippet verwende ich hier die neue Namespace-Variante, also ohne die „{}“ und einen zusätzlichen Einschub (ich liebe dieses Feature). Wenn Du noch mit der alten Syntax unterwegs bist, kannst Du Diese natürlich genauso gut verwenden. Umschließe dazu einfach das „MainViewModel“ – wie üblich – mit dem „namespace“-Schlüsselwort und „{}“ und setze die Klasse dort rein.

namespace DataGridBindingBeispiel.ViewModels;

public class MainViewModel
{

    public MainViewModel()
    {

    }

}

Namespace ViewModels

    Public Class MainViewModel
    
        Sub New()

        End Sub

    End Class

End Namespace

Den DataContext des MainWindows setzen

Nachdem Du nun das „MainViewModel“ erstellt hast, müssen wir Dieses, bzw. eine Instanz davon im nächsten Schritt verwenden. Ansonsten wüsste das „MainWindow“ nicht, wo es die zugrundeliegenden Daten für die Datenbindungs-Anweisungen findet. Lass uns den „DataContext“ des „MainWindows“ nun im Code-Behind-File des Views setzen.

Dorthin gelangst Du, indem Du einfach die F7-Taste drückst, während Du im XAML-Designer des „MainWindows“ bist:

using DataGridBindingBeispiel.ViewModels;

class MainWindow
{
    public MainWindow()
    {
        InitializeComponent();
        DataContext = new MainViewModel();
    }
}

Imports DataGridBindingBeispiel.ViewModels

Class MainWindow

    Sub New()
        InitializeComponent()
        DataContext = New MainViewModel()
    End Sub

End Class

Grundsätzlich weiß unser Hauptfenster also nun, wo es seine Daten finden kann, wenn wir eine Datenbindung verwenden. Das nächste Problem ist aktuell natürlich noch, dass im Datenkontext noch gar keine Daten vorhanden sind, an Welche gebunden werden könnte. Lass uns das also gleich erledigen, vorerst müssen wir leider noch etwas „erfinden“ – dazu im nächsten Abschnitt mehr.

Unser Model – womit arbeiten wir überhaupt?

Bevor wir gleich überhaupt „etwas“ anzeigen können, müssen wir uns über dieses „Etwas“ erst einmal Gedanken machen. In unserem heutigen Beispiel möchten wir z. B. Rechnungen im DataGrid darstellen. Dazu müssen wir unserem Programm jedoch zuerst beibringen, was eine Rechnung überhaupt ist – woher soll es das sonst wissen..

Bringen wir also im nächsten Schritt unserem Programm bei, was eine Rechnung ist. Erstelle dazu im Ordner „Models“ eine Klassen-Datei namens „Bill“ und schreibe den folgenden Code hinein. Achte auch hier selbstverständlich auf den korrekten Namespace!

💡 Hinweis: Natürlich werden wir hier keine vollständige Rechnung nachbauen, sondern nur eine für das Beispiel komprimierte Klasse/Variante. Beachte auch, dass wir beim VB.NET-Beispiel eckige Klammern brauchen, da „Date“ ein reserviertes Schlüsselwort, bzw. ein „DateTime“-Alias ist.

using System;

namespace Models
{
    public class Bill
    {
        public int Id { get; set; }

        public DateTime Date { get; set; }

        public Bill(int id, DateTime date)
        {
            Id = id;
            Date = date;
        }
    }
}

Namespace Models

    Public Class Bill

        Public Property Id As Integer

        Public Property [Date] As Date

        Sub New(id As Integer, [date] As Date)
            Me.Id = id
            Me.Date = [date]
        End Sub

    End Class

End Namespace

So, nun weiß unser Programm, was eine Rechnung ist und der nächste Schritt wäre dann, Rechnungen darzustellen. Dies besteht natürlich wieder aus einzelnen Schritten.

Eine erste Datenbindung

Gehe nun zurück in die „MainWindow.xaml“-Datei, dort werden wir jetzt die Tabelle, also das WPF DataGrid erstellen. Natürlich werden wir hier jetzt keine ausgefeilte UI bauen, sondern uns auf das DataGrid allein fokussieren. Schreibe wie für XAML üblich also nun ein öffnendes und schließendes DataGrid-Tag in den XAML Code.

Zusätzlich geben wir auch direkt die erste Datenbindung an:

<!-- MainWindow Rest ... -->

<DataGrid ItemsSource="{Binding Bills}">

</DataGrid>

<!-- ... -->

Damit sagen wir dem XAML-Code erstmal: „Hey, stelle hier bitte ein DataGrid dar und die dazugehörigen Einträge/Reihen, findest Du in der Bills-Eigenschaft“.

Der Code hätte aktuell außer einer Fehlermeldung noch nichts zur Folge. Wo schauen die Datenbindungs-Anweisungen nochmal nach? Richtig! Im DataContext, sprich unserer „MainViewModel“-Instanz! Dort gibt es bisher noch keine Art „Liste“ von Rechnungen. Aktuell kommt so nur ein Fehler namens „Kann Bills auf blabla nicht finden“.

Automatisch generierte Spalten im WPF DataGrid

Da wir gerade aber beim Thema XAML sind, stell‘ Dir einfach mal vor, wir hätten diese „Bills“ schon drin (dazu kommen wir gleich selbstverständlich auch noch). Aktuell würde das „DataGrid“ alle Spalten anhand der Eigenschaften der zugrundeliegenden Objekte automatisch generieren. Dies sähe erstmal so aus:

Ich sag mal so: Cool, aber auch irgendwie uncool.. Die meisten deutschen Nutzer würden sich direkt beschweren, was denn bitte ein „Date“ sein soll (bitte arg deutsch aussprechen – dann kommt der Effekt besser rüber). Ebenso ist die Darstellung, bzw. das Format des Datums nicht wirklich toll – aber um beides kümmern wir uns nun!

Spalten & Formate selbst bestimmen

Bevor wir uns über die Darstellungs-Formate der jeweiligen Spalten Gedanken machen, müssen wir erstmal dafür sorgen, dass manuelle Spalten vorhanden sind. Das geht im WPF DataGrid ganz einfach, indem wir – eben XAML-typisch – eine Eigenschaft des DataGrids festlegen: „DataGrid.ColumnDefinitions“.

Gehe also wieder in den XAML-Code und zwischen die beiden DataGrid-Tags, dort erstellst Du ein öffnendes und schließendes Tag für die „ColumnDefinitions“-Eigenschaft. Dort drin fügen wir unsere Spalten-Definitionen hinzu. Für unser Beispiel haben wir erstmal eine simple Text-Spalte und eine Weitere mit einer Format-Angabe.

Der Kopf-Text der Spalte

Wir geben der jeweiligen Spalte einen „Header“-Wert, damit wir eine Spaltenüberschrift bekommen und danach noch die Datenbindungs-Anweisung. Bei der Id ist es relativ simple, da wir hier nur sagen: „Stelle hier einfach die Zahl der Id als Text dar“. Beim Datum sieht es anders aus, hier sagen wir erstmal, dass er das Datum nehmen, aber speziell formatieren soll. Dies erreichen wir innerhalb der Binding-Anweisung mit der Eigenschaft „StringFormat“.

Formatierung

Dort schreibst Du einfach zwei geschweifte Klammern-Paare, pass jedoch dabei auf, die Autovervollständigung grätscht hier öfters mal dazwischen. Im zweiten Paar geben wir zuerst den zu verwendenden Wert an (in diesem Fall den ersten Wert = Index 0), Welchen wir dann mit „dd.MM.yy HH:mm“ formatieren möchten.

        <DataGrid ItemsSource="{Binding Bills}">
            <DataGrid.Columns>
                <DataGridTextColumn Header="Nr." Binding="{Binding Id}" />
                <DataGridTextColumn Header="Datum" Binding="{Binding Date, StringFormat={}{0:dd.MM.yy HH:mm}}" />
            </DataGrid.Columns>
        </DataGrid>

Automatische Spalten-Generierung deaktivieren

Das Ganze sieht dann nun wie gleich folgend aus. Wie Du sicherlich sehen wirst, haben wir das Problem, dass nun 4 Spalten sichtbar sind. Das liegt daran, dass das DataGrid nach wie vor die Spalten generiert, dies müssen wir deaktivieren!

Die automatische Generierung der Spalten deaktivierst Du mit der „AutoGenerateColumns“-Eigenschaft des WPF DataGrids. Mit ausgeschalteter Spalten-Generierung sieht es dann final so aus:

Selbstverständlich hält Dich auch hier nichts davon ab, die „Header“-Eigenschaft zu binden und dynamischen Inhalt wie z. B. Übersetzungen darzustellen.

Die Datengebundene Liste befüllen

Nachdem wir nun alle Vorbereitungen soweit abgeschlossen haben, kümmern wir uns um die eigentlichen Rechnungen. Einerseits werden wir hierfür eine passende Art von Liste erstellen und zusätzlich befüllen. Leider reicht eine normale Liste, also eine gängige „List(Of T) & List<T>“ nicht aus, da Diese keine Änderungen kommunizieren kann.

Kommunizieren von Listen-Änderungen

Für gewöhnlich nimmt man hier die „ObservableCollection“, bzw. einen Listen-Typ, Welcher die „INotifyCollectionChanged“-Schnittstelle implementiert. Elemente, Welche Listen-Änderungen an das gebundene Steuerelement kommunizieren möchten, können diese Schnittstelle implementieren. Um dies zu tun, lösen die implementierenden Klassen das „CollectionChanged“-Ereignis aus.

MainViewModel erweitern

Nun fügen wir dem „MainViewModel“ die passende Eigenschaft hinzu. Beachte, dass ich hier nur einen „Getter“ definiere, da wir die Liste nicht mehrfach setzen werden. Wir instanziieren Diese nur einmal im Konstruktor und befüllen Sie anschließend bei Bedarf mit Daten. Natürlich können wir die Liste auch zu passenden Zeitpunkten leeren.

Nach der Instanziierung der Liste fügen wir noch ein paar Einträge (natürlich in Form von Rechnungen) hinzu.

using System.Collections.ObjectModel;
using DataGridBindingBeispiel.Models;

namespace DataGridBindingBeispiel.ViewModels;

public class MainViewModel
{

    public ObservableCollection<Bill> Bills { get; }

    public MainViewModel()
    {
        Bills = new ObservableCollection<Bill>();
        Bills.Add(new Bill(1, DateTime.Now));
        Bills.Add(new Bill(2, DateTime.Now));
    }

}

Imports System.Collections.ObjectModel
Imports DataGridBindingBeispiel.Models

Namespace DataGridBindingBeispiel.ViewModels

    Public Class MainViewModel

        Public ReadOnly Property Bills As ObservableCollection(Of Bill)

        Public Sub New()
            Bills = New ObservableCollection(Of Bill)()
            Bills.Add(new Bill(1, Date.Now))
            Bills.Add(new Bill(2, Date.Now))
        End Sub

    End Class

End Namespace

💡 Hinweis: Wir benutzen die aufeinanderfolgenden „Add“-Aufrufe nur, weil es hier mehr oder weniger die Basis ist. In einem realen Projekt sollte man eine bessere Implementierung einer INotifyCollectionChanged-Schnittstelle verwenden, da jeder „Add“-Aufruf hier einmal „Hey, es hat sich was geändert“ schreit. Dies ist natürlich völliger Quatsch! Schaue für eine beispielhafte Implementierung in den nächsten Abschnitt.

Im besten Fall sammelt man vorher einmal alle Items und fügt Diese in einem Schritt hinzu. Das hat den offensichtlichen Vorteil, dass die eigentliche (datengebundene) Liste nur ein einziges Mal „Hey, ich hab mich geändert“ auslöst – statt 200x für 200 Einträge.. Dies könnte im ersten Schritt z. B. durch eine Art Service passieren, oder im Testfall wie folgt:

var list = new List<Bill>();
// triggert kein CollectionChanged!
list.Add(new Bill(1, DateTime.Now));
// triggert auch kein CollectionChanged!
list.Add(new Bill(2, DateTime.Now));

// triggert CollectionChanged!!
// Achtung: Gibt es leider nicht standardmäßig!
Bills.AddRange(list);

Dim list = New List(Of Bill)()
' triggert kein CollectionChanged!
list.Add(New Bill(1, Date.Now))
' triggert auch kein CollectionChanged!
list.Add(New Bill(2, Date.Now))

' triggert CollectionChanged!!
' Achtung: Gibt es leider nicht standardmäßig!
Bills.AddRange(list)

Eine ObservableRangeCollection – AddRange zur Hand!

Wie im vorherigen Abschnitt erwähnt, gibt es Performance und – naja es fühlt sich halt nicht richtig an – Sauberkeits-Probleme, wenn wir die normale „ObservableCollection“ verwenden. Sie triggert für jeden hinzugefügten oder gelöschten Eintrag das „CollectionChanged“-Ereignis, was blöd ist, wenn das 200x in wenigen Millisekunden passiert.

Daher kannst Du Dich an folgender Klasse orientieren, Welche eine „AddRange“-Methode anbietet. Diese triggert das „CollectionChanged“-Ereignis bei der Verwendung der Methode nur ein einziges Mal! Google dazu am besten einfach mal nach „ObservableRangeCollection“.

Mit ausgewähltem Item arbeiten

Jetzt, wo die Liste an sich erstmal funktioniert, kümmern wir uns im letzten Schritt um eine weitere wichtige Funktionalität: Die Auswahl eines Eintrages. Hierbei spielt es natürlich auch eine Rolle, ob wir den Eintrag aus dem Code, bzw. durch die UI heraus setzen. Also, grundsätzlich zumindest, wir können es uns aber ziemlich einfach machen, da wir mit Zweiwege-Datenbindungen arbeiten.

Bevor wir das allerdings ans Laufen bekommen, fehlt vorher noch eine weitere Sache. Auch hierbei wäre es wieder ratsam, wenn Du Dir zum tieferen Verständnis meinen Beitrag über die „INotifyPropertyChanged“-Schnittstelle anschaust.

Das PropertyChangedBase-Helferlein

Der Einfachheit halber, werden wir von der dort gezeigten „PropertyChangedBase“-Klasse erben. Diese Klasse vereinfacht uns das Auslösen des „PropertyChanged“-Ereignisses, Welches der grafischen Oberfläche alles Notwendige signalisiert. Kopiere Dir die Klasse daher gerne in einen „Utils“-Ordner und packe Sie in den entsprechenden Namespace:

using System.Runtime.CompilerServices;
using System.ComponentModel;

namespace Utils
{
    public abstract class PropertyChangedBase : INotifyPropertyChanged
    {
        protected void NotifyOfPropertyChange([CallerMemberName] string? propertyName = null)
        {
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
        }

        public event PropertyChangedEventHandler PropertyChanged;
    }
}

Imports System.ComponentModel
Imports System.Runtime.CompilerServices

Namespace Utils

    Public MustInherit Class PropertyChangedBase
        Implements INotifyPropertyChanged

        Protected Sub NotifyOfPropertyChange(<CallerMemberName> Optional propertyName As String? = Nothing)
            RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(propertyName))
        End Sub

        Public Event PropertyChanged As PropertyChangedEventHandler Implements INotifyPropertyChanged.PropertyChanged

    End Class

End Namespace

💡 Hinweis: Lasse nun Dein „MainViewModel“ von dieser Basis-Klasse erben, oder implementiere das „INotifyPropertyChanged“-Interface manuell!

Eine SelectedBill-Eigenschaft

Füge im nächsten Schritt nun eine „SelectedBill“-Eigenschaft im ViewModel hinzu. Diese erlaubt uns die Datenbindung der ausgewählten Rechnung aus dem Datagrid. Das schöne ist, es funktioniert in beide Richtungen! Bedenke hier, dass Du das oben im blauen Hinweis angegebene Interface implementierst, oder von meine Beispiel-Basisklasse erbst!

Die „SelectedBill“-Eigenschaft hat hier einen speziellen „Setter“. Falls der sich hinter dem Feld befindliche Wert nicht von dem via „Setter“ übermittelte Wert unterscheiden sollte, springen wir heraus. Warum sollten wir auch „es hat sich was geändert“ auslösen, wenn dem nicht so ist. Wenn sich allerdings was geändert hat, kommunizieren wir dies via „PropertyChanged“-Ereignis nach außen.

Somit können alle interessierten Objekte auf ihre Art – wie das DataGridView – darauf reagieren.

using System.Collections.ObjectModel;
using DataGridBindingBeispiel.Models;
using DataGridBindingBeispiel.Utils;

namespace ViewModels
{
    public class MainViewModel : PropertyChangedBase
    {
        public ObservableCollection<Bill> Bills { get; set; }

        private Bill _selectedBill;

        public Bill SelectedBill
        {
            get
            {
                return _selectedBill;
            }
            set
            {
                if (_selectedBill == value)
                    return;
                _selectedBill = value;
                NotifyOfPropertyChange();
            }
        }

        public MainViewModel()
        {
            Bills = new ObservableCollection<Bill>();
            Bills.Add(new Bill(1, DateTime.Now));
            Bills.Add(new Bill(2, DateTime.Now));
        }
    }
}

Imports System.Collections.ObjectModel
Imports DataGridBindingBeispiel.Models
Imports DataGridBindingBeispiel.Utils

Namespace ViewModels

    Public Class MainViewModel
        Inherits PropertyChangedBase

        Public Property Bills As ObservableCollection(Of Bill)

        Private _selectedBill As Bill

        Public Property SelectedBill As Bill
            Get
                Return _selectedBill
            End Get
            Set(value As Bill)
                If _selectedBill Is value Then
                    Return
                End If
                _selectedBill = value
                NotifyOfPropertyChange()
            End Set
        End Property

        Sub New()
            Bills = New ObservableCollection(Of Bill)()
            Bills.Add(New Bill(1, Date.Now))
            Bills.Add(New Bill(2, Date.Now))
        End Sub

    End Class

End Namespace

💡 Hinweis: Wenn Du eine Standard-Auswahl, bzw. eine Auswahl aus dem Code heraus treffen möchtest, kannst Du der Eigenschaft einfach einen Wert zuweisen.

Das Setzen der ausgewählten Rechnung aus dem Code heraus könnte so aussehen:

// zweite Rechnung standardmäßig auswählen
SelectedBill = Bills[1];

' zweite Rechnung standardmäßig auswählen
SelectedBill = Bills(1)

Datenbindung anpassen

Final können wir nun noch einmal in den XAML-Code gehen, um die bisherige Datenbindungen des DataGrids zu verändern. Bisher weiß das WPF DataGrid natürlich nichts von der „SelectedBill“-Eigenschaft in unserem Viewmodel. Dies ändern wir nun mit der folgenden Bindung an die „SelectedItem“-Eigenschaft des Datagrids:

<!-- restlicher MainWindow.xaml Code.. -->

<DataGrid ItemsSource="{Binding Bills}" SelectedItem="{Binding SelectedBill}" AutoGenerateColumns="False">
    <DataGrid.Columns>
        <DataGridTextColumn Header="Nr." Binding="{Binding Id}" />
        <DataGridTextColumn Header="Datum" Binding="{Binding Date, StringFormat={}{0:dd.MM.yy HH:mm}}" />
    </DataGrid.Columns>
</DataGrid>

<!-- restlicher Code.. -->

Der Beitrag Der ultimative WPF DataGrid MVVM Guide in 2026 – C# & VB.NET erschien zuerst auf Robert Skibbe.