Visual Basic NET lernen möchte wirklich gelernt sein. Ich erinnere mich zu gut an meine Anfänge um das Jahr 2007 herum. Obwohl ich vermutlich wie jeder Anfänger alles Mögliche versucht habe in mein Gehirn aufzusaugen, gab es viele Schwierigkeiten. Es ging dabei in erster Linie nicht darum, dass das vermeintlich Gelernte nicht funktioniert hat! Es war viel mehr ein Problem, an benötigte Informationen zu kommen, bzw. das wonach ich suchte überhaupt betiteln zu können!

Klicke auf den nachstehenden Button, um Dich direkt als Schüler zu registrieren (keine Angst, erstmal nur eine unverbindliche Anfrage). Besuche alternativ meine Unterseite zum VB.NET Unterricht und erfahre mehr durch z. B. meine dafür vorbereitete Präsentation.

Läuft doch, aber!?

Eine extrem wichtige Rolle – wie ich mit den Jahren an Erfahrung festgestellt habe – spielt gerade die Qualität des Codes. Und was das WIRKLICH heißt, lernt man erst mit Praxiserfahrung, Code-Reviews und bei der Arbeit in Teams. Zu meinen Anfängen bin ich mit völlig anderen Augen an die Sache gegangen. In erster Linie war es mir wichtig, dass der Code, den ich schreibe, überhaupt funktioniert. Ich wollte, dass das Programm genau das von mir Erdachte macht.

Warum Visual Basic NET lernen?

„Warum sollte ich Visual Basic NET lernen?“. Diese Frage habe ich mir am Anfang natürlich auch gestellt, da kann ich Dich beruhigen! Ebenso habe ich mich gefragt: „Warum sollte ich gerade VB.NET lernen?“. VB.NET, wie es abgekürzt heißt, ist für mich eine der absolut tollsten Sprachen für Einsteiger. Allerdings soll das auf keinen Fall heißen, dass diese Programmiersprache nur für Einsteiger ist. Es ist damit möglich, alles vom Hobby- bis zum Enterprise-Niveau zu entwickeln.

Einfacher Einstieg möglich

VB.NET glänzt vor allem bei Anfängern durch die Orientierung an der englischen Sprache. Das macht es den Menschen wesentlich einfacher, Welche noch nicht so in der Programmier-Materie drin stecken. Diese Menschen finden sich daher oft vergleichsweise einfacher in die Thematik ein.

Für Quereinsteiger geeignet

Visual Basic NET ist wie oben bereits erwähnt im Vergleich zu anderen Programmiersprachen einfach(er) zu erlernen. Daher ist die Sprache auch meiner Meinung nach eher als andere Programmiersprachen für Quereinsteiger geeignet. Einen gewissen Hang zu Sprachen im Allgemeinen ist von Vorteil. Ebenso vorteilhaft ist natürlich eine gewisse Basis an Englisch-Kenntnissen. Besonders wenn es um Dokumentationen geht, bleibt einem häufig nur die englische Sprache.

Der Beginn der Programmierer-Karriere

Als ich meine persönlichen ersten Gehversuche in der Softwareentwicklung gemacht habe, war ich mit „Unmanaged C“-Code maßlos überfordert. Ich sah die ganzen kryptischen Symbole und hatte einige Zeit versucht, mich dort zurechtzufinden, jedoch erfolglos. Sicherlich hatte ich einige kleine Programme mit entsprechender Zeit zum Laufen bekommen, aber es war insgesamt nicht zufriedenstellend. Zuletzt habe ich mich dann vor lauter Frust dazu entschieden, „Unmanaged C“ vorerst ruhen zu lassen.

Mein Interesse an der Programmierung an sich, wurde dadurch keinesfalls vermindert, im Gegenteil. Kurze Zeit darauf bin ich dann durch Zufall auf Visual Basic NET gestolpert. Ich kann aus eigener Erfahrung sagen, dass mir VB.NET damals den Einstieg in die Welt der Programmierung ermöglicht hat. Schnell konnte ich mich in die englische Syntax einfinden und schnellstens eigene kleine Programme erstellen.

Die Hindernisse im Lernprozess

Auf dem Weg des Programmierers gibt es viele Hindernisse. Einige davon lassen sich sicherlich vermeiden. Hingegen lassen sich andere Hindernisse eventuell nur optimieren. Leider gibt es aber auch viele Hindernisse, Denen man sich zwangsweise stellen muss.

Wonach suche ich eigentlich?

Eins der Hauptprobleme als Programmier-Anfänger ist, dass man die zu suchenden Sachen häufig nicht betiteln kann. Woher soll man wissen, dass man nach einem „vertikalen Label“ suchen soll, wenn man nicht weiß, dass es Label heißt? Wie soll man erkennen, dass man nach „Handler dynamisch hinzufügen“ suchen müsste, wenn man nicht weiß, was ein „Handler“ ist? Man kann natürlich die für sich bekannten, oder logisch erscheinenden Wörter verwenden, aber ob das dann zum Ziel führt – häufig ja, jedoch ebenso häufig, nein.

Schreib, schreib, schreib den Code!

Auch wenn es nervig klingt und oft auch sehr viel Arbeit ist: Tippe alles mindestens – und ich meine wirklich mindestens – dreimal ab! So groß die Verführung – auch von meinen Code-Snippets oder Projekten – ist, tippe selbst! Nur so prägt sich das Genannte ein und Du hast nachher den Kopf frei für „wie setze ich die Logik um“ und nicht „Ach verdammt, wie ging nochmal eine Verzweigung?“. Du kannst noch so oft kopieren und zum Laufen bringen. Du kannst noch so oft vor dem Bildschirm sitzen und Dir nickend „hab ich verstanden“ denken. Sobald Du dann – häufig – selbst davor sitzt und es „los geht’s“ heißt, wirst Du Dich „wie ging das nochmal?“ fragen. Daher: Schreib, schreib, schreib den Code!

Foren und deren Mitglieder

Bevor ich genauer auf das Thema Foren eingehe, möchte ich hier erwähnen, dass nicht immer alle Fragestellungen – sagen wir mal – „optimal“ formuliert sind. Daher sind „schlechte“ Antworten teilweise nicht so verwunderlich. Allerdings setze ich im Folgenden voraus, dass eine angemessene Frage gestellt wurde.

Das setzt neben der korrekten Fragestellung auch eine entsprechende Vorrecherche und eventuell vorhandenes Test-Material voraus. Man möchte seinen potenziellen Helfern natürlich alle möglichen Informationen zur Verfügung stellen.

Auch wenn ich jetzt vermutlich ein Feuerwerk entzünde, ist das eben so… Dennoch warne ich vor! Foren mögen freilich auch ihr Gutes haben, allerdings wundere Dich nicht, wenn Du dort:

• unfreundlich behandelt wirst
• motiviert wirst, Dein Projekt aufzugeben
• Diskussionen führen musst, wo Du Dich fragst: „Muss das sein?“
• bombardiert wirst, was Du denn alles falsch machst
• ewig auf Antworten wartest

Varions Video zum Thema

Hier findest Du eine lustige Parodie von dem YouTube-Kanal „Varion“. So lustig diese Parodie auch sein mag, es entsprecht schon ziemlich der Realität.

Mein klares Wort dazu

Mein klares Wort dazu ist Folgendes: Machen! Du wächst nicht über Dich hinaus, wenn Du Dich nicht selbst forderst. Das soll natürlich nicht bedeuten, dass Du Dich ständig in komplexe Sachen verirrst, für die Du keinerlei Basis hast, aber es soll auch nicht heißen, dass Du deine Ziele und Wünsche dafür fallen lässt. Wenn Du vorhast Projekt X zu realisieren, dann tu es! Lerne dafür, was notwendig ist und wenn Du es Dir 17 Mal anschaust. Dafür kannst Du durch die „heutigen“ Möglichkeiten: Videos pausieren, Arbeitsblätter beschreiben, Apps verwenden und und und! Lass Dir nicht von den Leuten aus Foren etc. – oder von irgendwem anders – sagen, was Du zu tun und zu lassen hast, bzw. ob es „Sinn“ ergibt, was Du da tust. Wer etwas mit Willen / Disziplin und eigener Motivation macht, lernt besser.

Schlechte Code-Qualität

Ein weiteres Problem im Lernprozess von Visual Basic – und vielen anderen Dingen – ist die Qualität der Quelle und des Codes selbst. Was hab ich mich am Anfang toll gefühlt, als ich meine erste Datenbankanwendung zum Laufen bekommen habe – ach ja.. Um so genervter war ich dann, als ich gemerkt habe, dass das Ganze zwar funktioniert hatte, aber völlig unsicherer Quatsch war. Verbindungen, die nicht sauber geschlossen werden, Verbindungsdetails, die jeder aus der ausführbaren Anwendung auslesen konnte und und und – ein Graus!

Falscher Geiz

Oh man, bei diesem Thema muss ich mir selbst ordentlich an den Kopf fassen. Die menschliche Psyche ist ein wenig komisch. Ich selbst kenne diese Vorgehensweise – vor allem aus meinen Anfangszeiten – sehr gut. Lieber geht man hin, investiert 2 Tage, 3 Tage und sucht wie ein Irrer und verballert so seine wichtige Zeit, anstatt einfach die paar Euronen in die Hand zu nehmen und zu investieren. Es gibt so viele Zweigstellen – nicht nur in der Programmierung – an denen man sich in die falsche Richtung verirren kann, bzw. wo man gar nicht erst zum Ergebnis kommt. Man sollte man sich überlegen, von welcher Ressource man mehr hat: Zeit, oder Geld? Wenn ich ganz klar sagen kann: „Hey, mich stört es nicht, wenn ich jetzt 3 Tage zeitlich investiere.“, dann ist alles okay. Aber auch ich habe als Mensch mit starkem finanziellen Bewusstsein verstanden, dass die Investition manchmal der klügere „Trade“ ist.

Der Einarmige Bandit – Ein beliebtes Projekt

Nachfolgend möchte ich Dir ein sehr beliebtes Projekt zeigen, wofür ich immer mal wieder angeschrieben werde. Das Projekt „Der einarmige Bandit“ war vor längerer Zeit aus Spaß entstanden. Es war eins dieser Projekte, wo ich mir dachte: „Ich möchte jetzt mal xy machen!”. Genau da kommen wir auf DEN Punkt zu sprechen: Programmieren zu können bzw. zu lernen, bedeutet sich Freiheit zu schaffen. Ich kann als Entwickler frei entscheiden, was ich programmieren möchte!

Zeitmangel

Die Zeit jeder Person ist heutzutage rar. Die Menschen leben im permanenten Stress und versuchen Zeit und Kosten zu sparen, wo es geht. Sobald man mit der Programmierung beginnt, wird man relativ schnell verstehen, dass es häufig um Geschwindigkeit und diesbezüglicher Entscheidungen geht. Nehme ich mir die Zeit heraus, jetzt nochmal alles durchzuplanen und eventuell zu verbessern? Oder lasse ich es so wie es ist – es funktioniert ja schließlich! Auch wenn es als Anfänger gängig ist, laufende Sachen auch laufen zu lassen. Früher oder später werden die Anforderungen mehr. Visual Basic NET zu lernen heißt im ersten Schritt nur, die besonderen Eigenschaften dieser objektorientierten Sprache und deren Syntax zu verstehen. Zu einem Programmierer-Dasein gehört aber noch viel mehr dazu!

Womit ich euch zu unterstützen versuche

Für den optimalen Lernweg habe ich hier drunter die wichtigsten Hilfe-Themen aufgelistet. Ich möchte euch damit die Möglichkeit bieten, die Such-Orgien zu vermeiden, die ich durchlebt habe. Obwohl es viele Foren, Bücher und natürlich auch Videos gibt, haben wir alle auch viele negative Erfahrungen gemacht.

Meine angebotene Hilfe

• YouTube Kanal – Problemlösungen, Beispiele und viel mehr
• Unterricht über Skype und Fernwartung
• Auftragsprogrammierung als normale Dienstleistung
• mehr in Planung…

Visual Basic NET lernen und anzuwenden zu können, bedeutet in erster Linie Freiheit. Ob man als Privatperson nun Hobby-Projekte umsetzen möchte, oder auch als (neben-) beruflichen Zweig gewerbliche Applikationen erstellt. Beides ist mit Visual Basic NET möglich. Das zu erwerbende, oder bereits erworbene Wissen kann ein gutes Grundgerüst für eine Ausbildung, Festanstellung oder sogar die Selbstständigkeit sein.

Jederzeit wird es Dir möglich sein Beispielprojekte herunterzuladen, oder mir Fragen via Kontaktformular oder YouTube-Nachrichten zu stellen. Bitte schaue auch unter Empfehlungen vorbei, dort findest Du Materialien in verschiedenster Form, die mir persönlich sehr geholfen haben. Um meine freiwilligen Leistungen ein wenig zu honorieren, habe ich hier und da Anzeigen von Google platziert. Nach kurzer Zeit wirst Du merken, dass die Welt der Programmierung einige wundervolle Türen in jeder Hinsicht öffnen kann.

Der ideale Einstieg

Den idealen Einstieg in die Welt der Programmierung erhältst Du durch meine persönlich angebotenen Unterrichtsstunden via Fernwartung. Den Unterricht vor Ort habe ich mittlerweile so gut wie abgeschafft, da meine Schüler zumeist aus weiterer Entfernung kommen. Falls Du doch in greifbarer Nähe wohnen solltest und Interesse hast, schreibe mich gerne an, dann können wir schauen, was sich machen lässt.

Der Beitrag Visual Basic .NET lernen erschien zuerst auf Robert Skibbe.

Um Fortschritt in der Taskleiste, bzw. im Icon der Taskleiste anzuzeigen, kannst Du z. B. bei WPF-Anwendungen die „TaskbarItemInfo“-Klasse verwenden. Setze einen passenden Zustand in die „ProgressState“-Eigenschaft (z. B. „Normal“) und einen entsprechenden Fortschritt via „ProgressValue“-Eigenschaft.

Eine ProgressBar in der Taskleiste? Nice!

Yes! Gerade eben bin ich mit den einzelnen Teilen meines aktuellen YouTube-Videos fertig geworden. Und jetzt? Naja, jetzt muss ich das Ganze noch schneiden! Dazu verwende ich immer das bekannte Programm „DaVinci Resolve“. Alles zurechtgerückt und geschnitten, startete ich also im nächsten Schritt den Render-Prozess und da kam es mir in den Kopf!

Wenn Du es eilig hast, kannst Du natürlich die obigen Kapitel aus dem Inhaltsverzeichnis nutzen. Springe zum Beispiel hier zum WPF- und hier zum Windows Forms Beispiel.

In der Taskleiste sah ich die Fortschrittsanzeige (ProgressBar), Welche unter dem Taskleisten-Icon angezeigt wird. An der Stelle habe ich mich dann gefragt: „Öhm, hast Du als YouTuber im Bereich .NET überhaupt schon ein Tutorial dazu gemacht?“. Die Antwort war – nein! Also begann ich im nächsten Schritt direkt mit diesem Beitrag hier, wozu auch bald darauf das Video erscheinen wird.

Im Videoformat

Zu viel Text? Keine Sorge, schaue Dir einfach das passende YouTube-Video auf meinem Kanal an. So kannst Du Dir alles in Ruhe anschauen und Dich berieseln lassen. Ich rate Dir dennoch – zumindest ergänzend zum Beitrag – da ich hier nochmal alles im Detail erkläre.

Ein Beispiel

Wie gleich folgend könnte es z. B. in Deinem Programm (bei mir unter Windows 11) aussehen. Ich habe (wie Du unten noch sehen wirst) den Fortschritt jede Sekunde erhöht. Das hat natürlich zur Folge, dass diese kleine Fortschrittsbalken unter dem Icon wächst.

Besonders für Rendering-Softwares oder Programmen mit ähnlich langen Prozessen meines Erachtens nach unabdingbar! Alternativ gibt es auch noch eine Art „ich bin einfach busy“-Status, also wenn man den genauen Fortschritt vielleicht nicht darstellen kann.

Die TaskBarInfo-Klasse in WPF

Um unser Vorhaben, also eine Fortschrittsanzeige unter dem Programm-Icon in der Taskleiste umzusetzen, gibt es von WPF einfache Bordmittel. Hierbei handelt es sich um die „TaskbarItemInfo“-Klasse, Welche sich im „System.Windows.Shell“-Namespace versteckt. Diese, bzw. Instanzen davon bieten verschiedene Eigenschaften an, die wir mit passenden Werten versehen können.

Eine Fortschrittsanzeige zum Fenster hinzufügen

Um überhaupt eine Art Fortschritt anzeigen zu können, müssen wir erstmal eine passende Instanz der jeweiligen Klasse erstellen. Danach muss diese Instanz der passenden Window-Eigenschaft zugewiesen werden. Dadurch weiß das WPF-Fenster: „Aha, meine Info finde ich also da..“. Klingt kompliziert, ist aber eigentlich ganz einfach.

In typischer WPF-Manier, sprich im XAML-Code, sieht das dann wie gleich folgend aus. Problem ist nur, dass Du aktuell praktisch immer „30%“ als Fortschritt sehen würdest. Das liegt natürlich daran, dass wir den Wert für die „ProgressValue“-Eigenschaft hard gecoded haben.

<Window x:Class="blabla.MainWindow"
        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"
        mc:Ignorable="d"
        Title="MainWindow" Height="450" Width="800" Loaded="Window_Loaded">
    
    <Window.TaskbarItemInfo>
        <TaskbarItemInfo ProgressState="Normal" ProgressValue="0.3" />
    </Window.TaskbarItemInfo>
   
    <Grid>

    </Grid>
</Window>

Mögliche Zustände

Im nächsten Schritt können wir z. B. festlegen, was wir eigentlich darstellen möchten, z. B. eine Art Fehler im Vorgang. Oder wollen wir einfach nur den „normalen“ Fortschritt darstellen? Das machen wir mit der „ProgressState“-Eigenschaft, der „TaskbarItemInfo“-Klasse. Die gängigen Werte kannst Du hier nachlesen:

• None
• Normal
• Indeterminate
• Paused
• Error

Je nach Einstellung färbt sich die Fortschrittsanzeige in der Taskleiste dementsprechend. Ebenso haben wir dadurch die Möglichkeit, die ProgressBar zu deaktivieren, sowie auf eine Art „auf unbestimmte Dauer beschäftigt“ zu setzen. Für Letzteres ist z. B. der Zustand „Indeterminate“ gedacht.

Fortschritt verändern

Das obige Beispiel dürfte wie schon erwähnt relativ langweilig sein, da unser Fortschritt nur auf einer Stelle stehenbleibt. Gehen wir also nun die Fortschritts-Veränderung an, dazu brauchen wir nur die passende Eigenschaft im Code verändern. Beachte, dass „20%“ z. B. „0,2“ wären, nicht „20“!

Beachte ebenso, dass wir Zustandsveränderungen nur auf dem Thread der grafischen Oberfläche durchführen sollten. Ansonsten wirst Du vermutlich eine Cross-Thread Fehlermeldung bekommen! Schaue Dir zu diesem Thema gerne auch meinen „Beitrag zu ConfigureAwait“ und den Beitrag zum Thema „Ungültiger threadübergreifender Vorgang“ an.

Mit der „Thread-Kenntnis“ starten wir nun eine einfach „Fire and Forget“-Task, Welche den Fortschritt immer wieder nach kurzer Verzögerung anpasst. Dadurch, dass „ConfigureAwait“ standardmäßig auf „true“ steht, brauchen wir uns hier keine Gedanken über den Thread der Oberfläche machen. Denn so hüpfen wir immer wieder in den Ursprungs-Kontext = die grafische Oberfläche (um’s einfach zu halten..).

Generiere im nächsten Schritt einfach einen „Loaded“-Ereignishandler, indem Du innerhalb des Window-Tags „Loaded“ schreibst und dann Tab drückst. In den Bereich des Loaded-Handlers kannst Du dann folgenden Code unterbringen:

// sonstiger Fenster-Code

    private void Window_Loaded(object sender, RoutedEventArgs e)
    {
        _ = SimulateProgress();
    }

    private async Task SimulateProgress()
    {
        while (TaskbarItemInfo.ProgressValue < 1)
        {
            await Task.Delay(1000);
            TaskbarItemInfo.ProgressValue += 0.1;
        }
        Debug.WriteLine("completed!");
        TaskbarItemInfo.ProgressState = System.Windows.Shell.TaskbarItemProgressState.None;
    }

// sonstiger Fenster-Code

' sonstiger Fenster-Code

Private Sub Window_Loaded(sender As Object, e As RoutedEventArgs)
    Dim fireAndForgetTask = SimulateProgress()
End Sub

Private Async Function SimulateProgress() As Task
    While TaskbarItemInfo.ProgressValue < 1
        Await Task.Delay(1000)
        TaskbarItemInfo.ProgressValue += 0.1
    End While

    Debug.WriteLine("completed!")
    TaskbarItemInfo.ProgressState = System.Windows.Shell.TaskbarItemProgressState.None
End Function

' sonstiger Fenster-Code

Sobald das Fenster geladen ist, zeigen wir die ProgressBar an, denn wir haben Sie im MainWindow XAML-Code sichtbar geschaltet! Danach beginnt der Code von „SimulateProgress“ zu wirken. Wir warten letztendlich immer 1 Sekunde (solange wir nicht bei 100% sind). Und erhöhen dann die Fortschrittsanzeige um 10%. Wenn wir fertig sind, geben wir dies in einer kleinen Debug-Zeile aus und schalten die Fortschrittsanzeige aus.

Im Gegensatz zu vielen anderen Online-Codes, verzichte ich hier auf einen BackgroundWorker, dessen Benutzung Du gerne in meinem Background Worker Guide erfahren kannst. Ich bevorzuge die gezeigte Variante, wo wir eine einfache Task verwenden :).

Für Windows Forms

Wenn Du im Gegensatz zum obigen Beispiel die guten alten Windows Forms verwendest, bist Du hier natürlich ebenfalls genau richtig! Im Endeffekt ist die Verwendung der TaskBar und die darin befindlichen in Winforms nicht sooo viel schwerer. Das einzige Problem ist zunächst, dass Du auf „die TaskBar“ keinen so einfachen Zugriff hast.

Paket installieren

Um einen einfachen Zugriff auf die TaskBar zu erhalten, installierst Du einfach erst einmal folgendes Paket. Öffne dazu (wie so häufig im .NET-Bereich) den NuGet Paket-Manager. Dies kannst Du z. B. durch einen Rechtsklick auf Dein Projekt und dem passenden Menüeintrag machen. Entweder führst Du dann den unteren Befehl in der NuGet Konsole aus, oder suchst via GUI manuell nach dem Paket „WindowsAPICodePack-Shell“.

Install-Package WindowsAPICodePack-Shell

Mögliche Zustände

Nach der Installation des oben angegebenen Paketes, kannst Du analog zu den Zuständen oben, Ebendiese schalten. Diese befinden sich in einer Enumeration namens „TaskbarProgressBarState“.

Um zu einem jeweiligen Zustand zu schalten, verwendest Du nun die „SetProgressState“-Methode der „TaskbarManager“-Klasse, bzw. dessen „Instance“-Eigenschaft. Somit kannst Du nun zwischen den verschiedenen Modi wie „NoProgress“, „Indeterminate“ und mehr, hin und her schalten. Normal heißt auch hier: „Zeige einen Fortschritt an“.

TaskbarManager.Instance.SetProgressState(TaskbarProgressBarState.Normal, Handle)

Fortschritt verändern

Um den Fortschritt der Taskbar-ProgressBar nun zu verändern, kannst Du die analoge „SetProgressValue“-Methode verwenden. Hier setze ich z. B. „20%“ von „100%“ als aktuellen Wert:

TaskbarManager.Instance.SetProgressValue(20, 100, Handle)

Fortschritt ausblenden

Möchtest Du den Fortschritt wieder ausblenden, verwendest Du einfach dies hier:

TaskbarManager.Instance.SetProgressState(TaskbarProgressBarState.NoProgress, Handle)

Achtung: Bekannte Stolpersteine

Als ich das erste Mal mit der Thematik „ProgressBar in Taskleiste“ in Verbindung kam, hatte ich zumindest bei Windows Forms Projekten einige Probleme. Zuerst einmal fehlte die jeweilig verwendete Klasse und dann blieb der Aufruf wirkungslos, seufz.. Z. B. Folgendes ging nicht:

TaskbarManager.Instance.SetProgressState(TaskbarProgressBarState.Normal)

Das falsche Paket

Mit ein wenig Gefummel, habe ich dann rausbekommen, dass ich das falsche Paket installiert hatte, bzw. nicht alles. Ich hatte das „WindowsAPICodePack-Core“ installiert, allerdings hatte ich da keine Klasse namens „TaskbarManager“, auf die ich zugreifen, geschweige denn importieren konnte. Achte daher darauf, dass Du das korrekte Paket namens „WindowsAPICodePack-Shell“ installierst! Dann kannst Du zumindest die genannte Klasse namens „TaskbarManager“ verwenden.

Fehlendes Handle

Im nächsten Schritt stieß ich auf das Problem, dass die Aufrufe an sich durchgingen, aber irgendwie keine Wirkung hatten. Hier und da ein wenig rumprobiert, schon stieß ich auch auf die diesbezügliche Lösung: Man muss beim Aufruf ein Form-Handle angeben! Das Form-Handle der jeweiligen Form, für die ich eine ProgressBar in der Taskleiste anzeigen möchte. Gesagt, getan – aus Aufruf ohne Handle, wurde ein Aufruf mit Handle:

TaskbarManager.Instance.SetProgressValue(<currentValue>, <maxValue>, Handle)

Beachte hierbei, dass ich diesen Code aus der Form selbst aufrufe, nur deshalb habe ich hier den einfachen Zugriff auf dessen „Handle“-Eigenschaft!

Fehlende PresentationFramework Assembly

Die letzte Hürde ließ nicht lange auf sich warten, denn der geänderte Aufruf führte zu folgendem Fehler:

Auch dieser Fehler ist relativ einfach zu lösen! Mache einen Rechtsklick auf Dein Projekt, klicke auf Projektdatei bearbeiten, und füge die „UseWPF->True“ Konfiguration im Bild hinzu:

Downloads

Hast Du keine Lust alles händisch nachzubauen? Kein Problem, lade Dir doch einfach die gebrauchsfertigen Projekte herunter ;)!

Der Beitrag Fortschritt im Icon der Taskleiste mit C# oder VB.NET anzeigen erschien zuerst auf Robert Skibbe.

USB-Kommunikation zwischen SerialPort und Mikrocontroller

RFID-Chips für Zeiterfassungssysteme auslesen, mit LED’s spielen, oder anderer Interessanter Kram ist möglich – mit Mikrocontrollern. Der Bekannteste in der Mikrocontroller-Szene ist wohl der „Arduino“, Welcher mit seinen verschiedenen Ausfertigungen viele Bastler-Bedürfnisse abdeckt. Im heutigen Beitrag erfährst Du, wie Du gängige Mikrocontroller mit Hilfe der .NET SerialPort-Klasse via C#, oder auch VB.NET ansteuern kannst.

Du hast es eilig? Nutze gerne das Inhaltsverzeichnis, um an eine passende Stelle zu hüpfen! Du hast Anregungen? Ich habe mich vertan? Schreib gerne ein sachliches Kommentar in die Kommentar-Sektion weiter unten!

Eine kleine Einführung in Mikrocontroller

Im Endeffekt kann man Mikrocontroller als extremst kleine, erweiterbare Computer bezeichnen. Üblicherweise schließt man Diese mit daran verlöteten Dingen an z. B. PC’s an, oder lässt Sie im Solo-Betrieb laufen. So kann man einen Mikrocontroller beispielsweise anweisen, Temperatur-Daten zu sammeln und Diese via USB, oder sogar Wi-Fi zu übermitteln. Aufgrund ihrer Größe, sind Mikrocontroller jedoch häufig in Ihrer Leistung eingeschränkt. Heutzutage muss man glücklicherweise anerkennen, zu welcher Leistung Sie im Vergleich zu früheren Geräten fähig sind.

An dieser Stelle möchte ich jedoch nicht weiter, gar zu tief in die Materie abtauchen. Ich schätze, dass Dir bereits bewusst ist, was z. B. der Arduino, oder etwa ein Rasperry Pi ist. Vermutlich wirst Du gerade deswegen auf diesen Beitrag gestoßen sein: Du möchtest herausfinden, wie Du über .NET (egal ob nun Visual Basic .NET, oder C#) mit diesen Mini-PC’s kommunizieren kannst. Grundsätzlich geht das in .NET via der SerialPort-Klasse, Welche sich zu einem vorhandenen COM-Port verbinden kann.

Ab dann beginnt das Abenteuer aber erst, denn sich nur zu verbinden, reicht leider nicht aus!

Ein >wirklich< einfaches Beispiel – reicht es?

Da wir nun wissen, dass es die SerialPort-Klasse ist, Welche wir verwenden müssen, ist ja alles geklärt, oder!? Ich meine wir müssen doch dann eigentlich nur – eben typisch Objektorientierte Programmierung (OOP) – eine Instanz der jeweiligen Klasse erstellen und verwenden. Machen wir das doch einfach mal im ersten Schritt, wir erstellen eine Instanz der Klasse SerialPort.

Die Installation des System.IO.Ports NuGet-Paket

Bevor wir jedoch die SerialPort-Klasse verwenden können, müssen wir erst einmal das NuGet-Paket namens „System.IO.Ports“ installieren. Begib Dich dazu einfach auf einem der üblichen Wege in den genannten Paket-Manager. Z. B. durch einen Rechtsklick auf Dein Projekt im Projektmappen-Explorer und einem anschließenden Linksklick auf „NuGet-Pakete verwalten..“.

Nun suche nach dem jeweiligen Paket und installiere es. Wähle es dazu aus, begib Dich ins rechte Fenster und hake Dein Projekt an – final kannst Du dann „installieren“ drücken und die NuGet-Magie passiert.

Eine simple SerialPort-Instanz

Danach kannst Du endlich wie folgt eine einfache Instanz der SerialPort-Klasse erstellen. Hierbei geben wir in den meisten Fällen zwei wichtige Dinge an:

• Den zu nutzenden COM-Port
• Die zur Kommunikation verwendete Baudrate

In meinem Fall ist mein Arduino am „COM4“ angeschlossen, daher übergebe ich dies als String. Ebenso befindet sich Code auf meinem Arduino, Welche eine Verbindung mit der Baudrate „19200“ initialisiert. Damit keine komischen Zeichen bei uns ankommen, sollten wir auch seitens .NET die gleiche Baudrate verwenden.

Dim port = New SerialPort("COM4", 19200)

var port = new SerialPort("COM4", 19200);

Weitere Konfiguration

Neben den nun bekannten Einstellungen, gibt es noch Weitere, wie z. B. die Parität, die DataBits und die StopBits. Grundsätzlich reicht es meist aus, Diese Einstellungen auf ihren Standardwerten zu lassen. Dies passiert, wenn Du Sie wie im obigen Beispiel nicht angibst.

• Parität – Standardwert = Parity.None
• DataBits – Standardwert = 8
• StopBits – Standardwert = StopBits.One

Restliche Informationen dazu müsstest Du zumeist Deiner Gegenstelle, also dem Gerät entnehmen, zu dem Du Dich verbindest!

Und nü? Die Verbindung zum SerialPort öffnen!

Nun haben wir ein konkretes Objekt eines Bauplans (Klasse) namens „SerialPort“ erstellt, aber was nun? Nunja, bisher können wir nicht viel damit machen, denn die Verbindung ist noch nicht so wirklich hergestellt. Eine tatsächliche Verbindung zum Port öffnen wir einfach, indem wir die Open-Methode verwenden. Sprich also einfach Deinen eben erstellten Port an und verwende Ebendiese Methode:

Dim port = New SerialPort("COM4", 19200)
port.Open()

var port = new SerialPort("COM4", 19200);
port.Open();

Daten senden

Die schnellste und einfachste Möglichkeit Daten zu senden, ist die Vereinbarung eines Trennzeichens und das Abschicken, bzw. Auslesen von Daten, die dieses Trennzeichen beinhalten. Ein simples „Hin-und-her“ kann man also so durchführen:

Dim port = New SerialPort("COM4", 19200)
port.NewLine = vbLf
port.Open()
port.WriteLine("ID:?")

' blockiert solange BIS eine Antwort mit Daten UND dem vereinbarten Linefeed kommt!
Dim data = port.ReadLine()

var port = new SerialPort("COM4", 19200);
port.NewLine = "\n";
port.Open();
port.WriteLine("ID:?");

// blockiert solange BIS eine Antwort mit Daten UND dem vereinbarten Linefeed kommt!
var data = port.ReadLine();

Die Betonung liegt hier allerdings auf „simpel“, daher lies ruhig weiter und schaue Dir zum Beispiel besonders die Kapitel über Trennzeichen und Co. an.

Vorhandene COM-Ports auslesen / anzeigen

Im obigen Beispiel haben wir bisher nur einen fixen Port verwendet. Das ist nicht nur relativ unflexibel per se, sondern kann sich auch sogar je nach verwendetem Anschluss – trotz gleichem Gerät – am PC ändern. Schöner wäre es hingegen, wenn wir auflisten könnten, welche COM-Ports tatsächlich zur Verfügung stehen. Die gute Nachricht ist: Das ist ziemlich easy – wenn auch nicht immer ausreichend!

Kurz und bündig

Die einfachste Option, die vorhandenen COM-Ports auszulesen ist, die statische (in VB.NET „Shared“) SerialPort-Funktion namens „GetPortNames“ zu verwenden. Anzeigen könnte man diese Ports dann natürlich in jedem beliebigen Listen-Steuerelement, wie z. B. der ComboBox. Hier haben wir natürlich auch direkt die Möglichkeit, einen Port für unser Programm zu wählen.

Tipp: Direkt als bindungsfähige Liste

Ich empfehle hier übrigens die direkte „Umwandlung“ des zurückkommenden String-Arrays in eine BindingList. Wenn Du WPF verwendest, könntest Du hier eine passende Alternative, wie z. B. die ObservableCollection verwenden. Das bietet den Vorteil, später auf Veränderungen zu reagieren. Wir können dann z. B. bei Trennung einer physischen Verbindung den jeweiligen COM-Port entfernen, oder einen Port beim Herstellen einer USB-Verbindung der Auflistung hinzufügen.

Winforms-Beispiel

Public Class Form1

  ' sonstiger Form-Code..
  
  Public ReadOnly Property Ports As BindingList(Of String)

  Sub New ()
    Dim availablePorts = SerialPort.GetPortNames()
    Ports = New BindingList(Of String)(availablePorts)
    AddHandler Me.Load, AddressOf Form1_Load
  End Sub

  Private Sub Form1_Load(sender As Object, e As EventArgs)
    ComboBox1.DataSource = Ports
  End Sub
 
  ' sonstiger Form-Code..

End Class

public class Form1 : Form
{

  // sonstiger Form-Code..

  public BindingList<string> Ports { get; }

  public Form1()
  {
    var availablePorts = SerialPort.GetPortNames();
    Ports = new BindingList<string>(availablePorts);
    Load += Form1_Load;
  }

  private void Form1_Load(object sender, EventArgs e)
  {
    ComboBox1.DataSource = Ports;
  }

  // sonstiger Form-Code..

}

Daten zum Mikrocontroller schicken

Nachdem wir nun eine Möglichkeit gesehen haben, eine Verbindung zum Mikrocontroller aufzubauen, können wir nun weiter gehen. Das Wichtigste wäre wohl nun, tatsächliche Daten zum z. B. Arduino zu senden. Durch die serielle Verbindung (Serial…Port) schicken wir Daten – naja, eben seriell, sprich hintereinander – in die offene Verbindung. Die Reihenfolge der gesendeten Daten spielt hierbei natürlich eine essenzielle Rolle, da zuerst Gesendetes auch dementsprechend zuerst am Gerät ankommt. Schaue Dir gerne weiter unten die Write-, bzw. die WriteLine-Methode an.

Serielle Kommunikation & Protokoll

Dies sollte auch bei der Kommunikation im Allgemeinen beachtet werden, da hier eine Art parallele Kommunikation so natürlich relativ „unmöglich“ ist. Letztendlich entscheidet dann der Konsument über die passende Verarbeitung. Ich kann ja z. B. 3 Dinge kurz nacheinander empfangen, jedoch das Dritte Ding zuerst verarbeiten. Hierbei spielt also eine Art Protokoll, sowie eine Art Warteschlange eine sehr große Rolle.

Die Write-Methode

Verwende nun also den obigen Code, um eine Verbindung zum (erneut – z. B.) Arduino herzustellen und wähle dafür entweder die flexible „Auswahl-Methode“ der ComboBox, oder gebe den Portnamen fix an. Daten kannst Du dann ganz einfach via „Write“-Methode, bzw. eine der für Dich passenden Überladungen übersenden. Der Einfachheit halber, werde ich hier simple Strings übermitteln – ich verzichte also für’s Erste auf ein vollends implementiertes Protokoll. Schaue Dir alternativ auch die WriteLine-Methode an.

Strings an Arduino & Co. senden

Senden wir nun also einmal beispielhafte Daten an unseren Arduino. Dazu habe ich in diesem Beispiel einen kleinen Befehl aus meinem eigenen kleinen Protokoll verwendet. „ID“ spiegelt hier letztendlich eine Art Befehl und das „?“ die dazugehörige Statusabfrage wieder. Übersetzt könnte man sagen: „Ich möchte gerne Deine ID abrufen“.

Hierbei sollte man darauf achten, dass die SerialPort-Klasse (laut Doku) das ASCII-Encoding standardmäßig verwendet.

Dim port = New SerialPort("COM4", 19200)
port.Open()
port.Write("ID:?")

var port = new SerialPort("COM4", 19200);
port.Open();
port.Write("ID:?");

Bytes via Write-Methode senden

Wenn wir im Gegensatz zu einem String rohe Bytes schicken wollen, können wir dies natürlich auch sehr einfach tun. Dazu nutzen wir einfach die andere Überladung der „Write“-Methode. Hierbei müssen wir die Bytes mit einem passenden Encoding dann selbst erfassen. Dafür verwende ich hier beispielsweise das UTF8-Encoding:

Dim port = New SerialPort("COM4", 19200)
port.Open()
Dim textToSend = "ID:?"
Dim data = System.Text.Encoding.UTF8.GetBytes(textToSend)
port.Write(data, 0, data.Length)

var port = new SerialPort("COM4", 19200);
port.Open();
var textToSend = "ID:?";
var data = System.Text.Encoding.UTF8.GetBytes(textToSend);
port.Write(data, 0, data.Length);

WriteLine-Methode – mit Nachrichten-Trenner

„Das hat doch kein Ende..“ – das könnte man sich mit Sicherheit in so diversen alltäglichen Situation denken. Allerdings meine ich hier eher gesagt unsere Kommunikation zum Mikrocontroller, wie z. B. den Arduino. Mit unserem bisherigen Code weiß unser Kommunikationspartner leider gar nicht, wann eine „Nachricht“, oder eine Übermittlung beendet ist. Dem gleichen Problem treten wir auch entgegen, wenn wir die Richtung Arduino->.NET Software betrachten.

Für gewöhnlich verwendet man hier eine Art „Message-Terminator“, also eine Art Trennzeichen, Welches signalisiert: „Hey, ab hier ist die Übertragung der letzten Nachricht abgeschlossen“. Theoretisch könnte man natürlich auch – analog z. B. zu HTTP & Co. – eine Art Header senden. Hier muss man schlichtweg sein eigenes Protokoll wählen / designen, Welches für den jeweiligen Einsatz geeignet ist.

NewLine-Eigenschaft mit Trennzeichen

In unserem Beispiel können wir mit dem SerialPort vorab ein Trennzeichen über die „NewLine“-Eigenschaft vereinbaren. Ich weiß, ein verwirrender Name.. Setze nun einmal beispielhaft das „LineFeed“-Zeichen als das Trennzeichen ein, dies geht wie gleich folgenden. Beachte, dass zukünftige „WriteLine“-Aufrufe nun automatisch das Trennzeichen angeheftet bekommen! ReadLine wird hingegen solang blockieren, bis es dieses Trennzeichen ankommend vom Gerät bei einem Lesevorgang erkennt!

' irgendwo bei der Initialisierung..
_port = New SerialPort("COM4", 19200)
' hier setzen wir das Zeichen 10 -> Linefeed
' als Trennzeichen der Nachrichten ein!
_port.NewLine = vbLf

// irgendwo bei der Initialisierung..
_port = new SerialPort("COM4", 19200);
// hier setzen wir das Zeichen 10 -> Linefeed
// als Trennzeichen der Nachrichten ein!
_port.NewLine = "\n";

Nachwort zum Thema Protokoll

In meinerseits geschriebenen und professionell eingesetzten Anwendungen, habe ich hier ein ganzes Protokoll in Kombination mit dynamischen Zusammensetzungen von Maschinen-Objekten gebaut. Dies würde hier allerdings mehr als den Rahmen sprengen. Eventuell werde ich dies in einem zukünftigen Beitrag einmal demonstrieren.

Meines Erachtens nach ist dies der einzig richtige Weg, da man auf die obige Art und Weise ggf. schnell auf gewisse Grenzen stößt. Wenn ich z. B. warten möchte bis gewisse Aufgaben (siehe Tasks, TaskCompletionSources, etc.) erledigt sind, habe ich aktuell keine Ahnung, Welches herausgesendete Kommando, zu welcher eingehenden Antwort gehört.

Antwortdaten empfangen

Bisher war die Kommunikation mit der jeweiligen Gegenstelle relativ einseitig, oder? Es ist also mehr als an der Zeit, auch eine wirkliche Antwort des Geräts zu empfangen, sowie zu verarbeiten. Auch hier gibt es verschiedene Lösungen, von Denen ich schon Einige durch hatte. Viele Entwickler – darunter auch ich – erfuhren in Vergangenheit von gewissen Problemen, wie z. B. abgeschnittene Daten, usw.

Für unser Beispiel werde ich auch hier die womöglich einfachste Variante vorstellen. Melde Dich gerne in den Kommentaren unten, falls Du komisches Verhalten feststellen, oder etwas anderes zu berichten hast! Nun aber zurück zum eigentlichen Thema..

Polling ist „plöde“, gell!?

Wie schon erwähnt, gibt es verschiedene Möglichkeiten Daten aus dem SerialPort zu empfangen. Darunter wäre einerseits das typische Polling. Wenn Dir dieser Begriff nichts sagt, stell‘ Dir einfach das gute alte Kind auf dem Rücksitz vor: „Sind wir schon da?.. Sind wir schon da?.. Sind wir schon da?.. usw.“. Im Endeffekt fragt etwas einfach die Gegenstelle permanent, ob was anliegt, bzw. ob sich was geändert hat. Für gewöhnlich passiert das dann in einer Art Endlosschleife, oder a la „solange Gerät verbunden“.

Ereignisse zur Rettung!

Wenn wir also keine Lust auf das permanente, nervige und ineffiziente „Sind wir schon da?“ haben, brauchen wir eine Alternative. Dazu gibt uns die SerialPort-Klasse ein Ereignis namens „DataReceived“ mit an die Hand. Nun müssen wir also nur noch einen Handler an geeigneter Stelle verknüpfen und schon können wir die empfangenen Daten verarbeiten.

Ein einfaches Beispiel könnte dazu wie gleich folgend aussehen. Beachte hierbei, dass ich die Instanz des SerialPorts als Form-Member ausgelagert habe, damit ich auch in der Handler-Sub/-Void darauf zugreifen kann. Das Schreiben des „Befehls“ kann natürlich in z. B. einen Button-Click-Handler o. Ä. ausgelagert werden. Für ein einfaches Beispiel lasse ich es hier im Konstruktor.

Für das Auslesen der empfangenen Daten an sich (aus dem Puffer), verwende ich die „ReadExisting“-Funktion. Diese gibt uns einen String der aktuell vorhandenen Daten im Puffer zurück. Anschließend würde es dann Deinem Protokoll unterliegen, diesen String korrekt zu verarbeiten.

Achtung – Stückelungen möglich!

Hierbei ist es wie gesagt ganz wichtig zu verstehen, dass wir einfach nur einen Haufen serieller (aufeinanderfolgender) Daten bekommen. Diese kommen auch nicht unbedingt immer an einem Stück! Wenn ich in meinem vorherigen Beispiel z. B. „ID:?“ zum Arduino schicke, könnte ich die gesamte Antwort in einem Schritt bekommen: „ID:Arduino Nano“.

Es könnte aber auch genauso gut sein, dass ich erst „ID:“ beim ersten Aufruf des Ereignisses bekomme und dann in einem zweiten Durchlauf „Arduino Nano“. Das korrekte Auseinanderfriemeln bleibt also mehr oder weniger unsere Aufgabe!

Public Class Form1

  ' sonstiger Form-Code..

  Private _port As SerialPort
  
  Sub New ()
    _port = New SerialPort("COM4", 19200)
    AddHandler _port.DataReceived, AddressOf Port_DataReceived
    _port.Open()
    _port.Write("ID:?")
  End Sub

  Private Sub Port_DataReceived(sender As Object, e As SerialDataReceivedEventArgs)
    Dim data = _port.ReadExisting()
    Debug.Write($"data received: {data}")
  End Sub
 
  ' sonstiger Form-Code..

End Class

public class Form1 : Form
{

  // sonstiger Form-Code..

  SerialPort _port;

  public Form1()
  {
    _port = new SerialPort("COM4", 19200);
    _port.DataReceived += Port_DataReceived;
    _port.Open();
    _port.Write("ID:?");
  }
  
  private void Port_DataReceived(object sender, SerialDataReceivedEventArgs e)
  {
      var data = _port.ReadExisting();
      Debug.Write($"data received: {data}");
  }
  
  // sonstiger Form-Code..

}

Cross-Thread Probleme

Beachte, dass das DataReceived-Ereignis, bzw. dessen Handler auf einem Hintergrund-Thread ausgeführt wird. Um also auf die grafische Oberfläche zugreifen zu können, müsstest Du zurück auf Deinen UI-Thread „hüpfen“. Das funktioniert z. B. so:

    Private Sub Port_DataReceived(sender As Object, e As SerialDataReceivedEventArgs)
        Dim data = _port.ReadExisting()
        BeginInvoke(Sub()
                        TextBox1.AppendText(data)
                    End Sub)
    End Sub

private void Port_DataReceived(object sender, SerialDataReceivedEventArgs e)
{
  var data = _port.ReadExisting();
  BeginInvoke(() => TextBox1.AppendText(data));
}

Achtung – typische SerialPort Fehler!

Eigentlich ist der obige Code relativ simpel, aber natürlich stößt man auch hier auf gewisse Probleme. Was ist z. B., wenn ich einen COM-Port öffnen möchte, der gar nicht „existiert“!? Was, wenn ich einen bereits geöffneten COM-Port versuche, erneut zu öffnen? Die Antwort ist ganz einfach: Dann gibt es dazu passende Ausnahmen (Exceptions).

Öffnen eines nicht existenten COM-Ports

Der vermutlich häufigste Fehler ist gleichzeitig der Offensichtlichste: Du öffnest die Verbindung zu einem COM-Port, Welcher gar nicht verfügbar ist. Eventuell liegt es daran, dass der Nutzer in Deinen App-Einstellungen, in Vergangenheit einen falschen Port gewählt hatte. Vielleicht hat er/sie es auch einfach vergessen, das Gerät via USB anzuschließen.

In so einem Fall wird Dich mit aller Wahrscheinlichkeit der folgende Fehler begrüßen: System.IO.FileNotFoundException: „Could not find file ‚COM6‘.“.

Doppelte Verbindungen auf einem COM-Port

Versuchst Du z. B. eine COM-Port-Verbindung zu öffnen, obwohl Du bereits eine offene Verbindung hast, kommt es zu einem Fehler. Dies geschieht auch, wenn eine andere Software bereits die Verbindung auf diesem COM-Port geöffnet hat. Hierbei handelt es sich um die „UnauthorizedAccessException“ aus dem folgenden Bild. Dazu habe ich einfach zwei Instanzen der SerialPort-Klasse für den gleichen Port (COM4) erstellt und versucht, Beide zu öffnen:

Dim portA = New SerialPort("COM4", 19200)
Dim portB = New SerialPort("COM4", 19200)
portA.Open()
' wird einen Fehler werfen!
portB.Open()

var portA = new SerialPort("COM4", 19200);
var portB = new SerialPort("COM4", 19200);
portA.Open();
// wird einen Fehler werfen!
portB.Open();

Der resultierende Fehler: „System.UnauthorizedAccessException: „Access to the path ‚COM4‘ is denied.““

Komische Zeichen in den Antwort-Daten

Der wohl – ich würde sagen – dritt-häufigste Fehler ist es, komische Zeichen in seinen SerialPort Antwort-Daten zu haben. Da tauchen dann unter anderem komische Striche, bzw. auch Fragezeichen auf. Sieht häufig blöd aus, aber die Lösung ist eigentlich relativ einfach: Du verwendest eine falsche Baudrate! Ebenso kommt das Problem zustande, wenn Du schon einmal Daten mit falscher Baudrate gesendet hast und DANN auf die richtige Baudrate wechselst!

Im Screenshot kannst Du sehen, wie so eine „fehlerhafte“ Kommunikation aussehen könnte. Wenn Du im zweiten Versuch (nach dem Erhalt einer solchen Nachricht) eine erneute Nachricht sendest, sollte die Kommunikation normal laufen.

Downloads & Weiteres

Falls Du es eilig hast, oder einfach nur loslegen möchtest, kannst Du Dir das passende Beispielprojekt hier direkt herunterladen. Alternativ empfehle ich Dir auch die Verwendung eines meiner NuGet-Pakete, damit geht es ggf. ebenso schnell.

Der Beitrag .NET SerialPort-Kommunikation mit Arduino & Co. – 2024 Guide erschien zuerst auf Robert Skibbe.

Sauberere Programmierung durch Dependency Injection (DI)

Du möchtest Deinen VB.NET, bzw. C# Anwendungen einen „Level Up“ durch Dependency Injection (kurz DI) verpassen? Oder möchtest Du einfach mehr über „das Thema mit den Abhängigkeiten“ lernen? Anders gefragt: Baust Du Dir auch jedes Mal einen neuen Hammer, nur weil Du einen weiteren Nagel in die Wand hämmerst – ne, oder!?

Aus diesem und ähnlichen Gründen macht es auch in der Programmierung keinen Sinn. Welche das genau sind und wie wir unsere .NET Anwendungen mit DI verbessern können, schauen wir uns im heutigen Beitrag an 🤓! Stell‘ Dir einmal vor, Du gehst zum Zahnarzt und Du müsstest vorher selbst Dein Auto bauen. Beim Zahnarzt angekommen, müsste Dieser erstmal alle Geräte bauen und so setzt sich die Kette fort.. Bitte nicht!

Kurzanleitungen

Hast Du es eilig? Kenne ich.. Bekomme einen Überblick ohne Blabla, indem Du Dir dieser Kurzanleitungen anschaust. Wenn Du was nicht verstehst, oder mehr Infos benötigt, kannst Du zu den passenden Sektionen springen. verwende hierzu z. B. das Inhaltsverzeichnis. Lade Dir auch gerne den zu Deinem Projekt passenden Beispielcode herunter, Diesen findest Du unter „Downloads„.

Für VB.NET-Projekte

1. Installiere Autofac via NuGet Paket Manager
2. Erstelle die DebugLogger Klasse als Datei im Wurzelverzeichnis
3. Deaktiviere das Anwendungsframework in den Projekteinstellungen
4. Erstelle einen manuellen Start-Prozess
5. Falls 4 nicht funktioniert, passe das in der Projektdatei an
6. Instanziiere einen ContainerBuilder und registriere die Abhängigkeiten
7. Lass‘ den ContainerBuilder den Container erstellen und merke Dir Diesen in einer statischen Eigenschaft z. B. in der Program.vb
8. Lasse die Form vom DI zusammenbauen und zeige Sie an

Für C#-Projekte

1. Installiere Autofac via NuGet Paket Manager
2. Erstelle die DebugLogger Klasse als Datei im Wurzelverzeichnis
3. Instanziiere einen ContainerBuilder und registriere die Abhängigkeiten
4. Lass‘ den ContainerBuilder den Container erstellen und merke Dir Diesen in einer statischen Eigenschaft z. B. in der Program.vb
5. Lasse die Form vom DI zusammenbauen und zeige Sie an

Was ist Dependency Injection?

Nunja, bevor wir gleich überhaupt irgendwie mit dem „Wie“ starten können, sollten wir uns vorerst um ein grundsätzlich Verständnis über DI kümmern. Bitte bedenke, dass ich diesen Beitrag hier nicht sprengen möchte! Daher werde ich das Thema „Was ist Dependency Injection“, bzw. den Fokus auf der sachlichen DI-Thematik zu einem späteren Zeitpunkt, separat und in mehr Detail bearbeiten.

Grundsätzlich könnte man die zu Deutsch „Injektion von Abhängigkeiten“ wie folgt, ganz einfach und in ca. 2-3 Sätzen beschreiben:

1. Dependency Injection ist eine Planungs-/Vorgehensweise bei der Softwareentwicklung.
2. Dabei achtet man darauf, dass Objekte, weitere Objekte (Abhängigkeiten) bekommen, Welche Sie zur Erledigung ihrer Arbeiten benötigen.
3. Objekte erstellen also nicht selbst ihre notwendigen Werkzeuge / Abhängigkeiten.

Hierbei kann man ganz leicht viele Beispiele finden:

1. Der Programmierer mit seinem PC und Co.
2. Die Erzieherin im Kindergarten
3. Der Holzfäller mit seiner Axt
4. Die Friseurin mit Schere und Co.
5. oder auch der Taxifahrer mit seinem Fahrzeug.

Wie Du Dir schon vorstellen kannst, wäre es nicht wirklich effizient / toll, wenn jede dieser Personen ihre Werkzeuge selbst bauen müsste – ohoh.. Zum Schluss dieses Abschnitts noch ein Hinweis: Streng genommen geht DI auch noch mit einem anderen Prinzip namens „Inversion of Control“ kurz „IoC“ einher. Darüber würde ich dann aber in einem anderen, zukünftigen Beitrag philosophieren.

Warum ist DI gerade in .NET wichtig?

Auch wenn folgendes sicherlich ein gewagter Kommentar ist, werde ich Ihn trotzdem aussprechen. Die Erfahrungen aus den vielen Jahren meiner Entwicklerkarriere zeigen leider, dass besonders VB.NET-Entwickler gegen solche Dinge wie DI „verstoßen“, oder es für Viele eben ein Fremdwort ist. Klar, es ist letztendlich – wie immer – nur eine Art „Hilfs-Regelwerk“, aber man sieht schon allein an diesen Dingen häufig die tatsächliche Erfahrung eines Entwicklers. Ich behaupte: Jeder professionelle Entwickler sollte wissen, was DI ist, wo es konkret unterstützt und wie man es einigermaßen umsetzt.

Häufig höre ich von Menschen aus dem .NET-Umfeld: „Ich programmiere schon 30 Jahre“.. Das freut mich als .NET-Entwickler-Urgestein natürlich, allerdings bringt einem das gar nichts, wenn man selbst nach 30 Jahren immer noch nicht mit DI in Berührung gekommen ist. Ob man das jetzt für ein jeweiliges Projekt nutzt oder nicht, ist immer wieder eine neue Entscheidung. Häufig höre ich dies besonders aus dem VB.NET-Bereich, sprich meinen eigenen Wurzeln.

Bitte verstehe mich an dieser Stelle nicht falsch, ich möchte niemanden geißeln o. Ä., letztendlich ist es ja auch nie für Weiterbildung zu spät. Besonders in der IT gilt ja sowieso: „Bilde Dich weiter, oder Du bleibst auf der Strecke“ und final muss man selbst als Unternehmer oder Angestellter entscheiden, Welche Werkzeuge angesichts der jeweiligen Situation (Budget, Auflagen des Teams, etc.) zum gewünschten Endergebnis führen.

Los geht’s – Dependency Injection Helfer installieren

Nachdem Du nun einen kurzen Crashkurs in die Welt der Dependency Injection an sich erhalten hast, widmen wir uns nun der Programmierung – ich weiß, endlich.. Wie immer gilt: „Erfinde das Fahrrad nicht neu, außer es bringt Dir im Vergleich mehr Vorteile, als es Dich Zeit kostet“. Deshalb werden wir auch hier auf vorhandene und vor Allem etablierte Helferlein zurückgreifen.

Hierbei spreche ich von dem NuGet-Paket namens „Autofac“, Welches mit (aktuell) 201 Millionen Downloads eine ordentliche Hausnummer darstellt. Dementsprechend kann man sich natürlich auch dessen Resonanz in der Entwicklerszene vorstellen. Gehe also bitte für den Anfang hin und installiere dieses Paket aus dem NuGet Paket Manager.

Klicke dazu z. B. mit Rechtsklick auf Dein Projekt im Projektmappenexplorer (oben rechts – nicht auf die Projektmappe selbst!) und wähle „NuGet-Pakete verwalten“ aus. Danach suchst Du wie oben im Bild gezeigt nach „autofac“ und solltest den dementsprechenden Eintrag finden.

Wähle das Paket aus und bestätige die Installation für Dein Projekt auf der rechten Seite des aktuellen Fensters. Nach einem kurzen Moment sollte die Installation abgeschlossen und durch einen kleinen Haken auf dem Icon (links) bestätigt sein. Manchmal hängt Visual Studio jedoch, bzw. ist ein wenig buggy, öffne den NuGet Paketmanager dann einfach nochmal.

Injizierbares Werkzeug erstellen

Um einem Objekt ein anderes, weiteres Objekt zur Verfügung zu stellen (es zu injizieren), benötigen wir erst einmal das Erste. Objekt A wird in unserem Beispiel die obligatorische „Form1“ sein, denn Diese haben wir bereits beim Start eines neuen Projekts. Auch in WPF-Anwendungen können selbstverständlich ähnlich verfahren. Ich denke jedoch, dass jeder .NET-Entwickler die guten alten Windows Forms kennt, daher fange ich der Einfachheit halber damit an.

Nun erstellen wir das Werkzeug, Welches in die Form1 injiziert werden soll. Natürlich kann es anschließend auch in viele andere Ziele injiziert werden.

Erstelle nun eine Klasse namens „DebugLogger“, Welche nur eine kleine Methode namens „Log“ beinhalten wird. Ich möchte den Fokus an dieser Stelle nicht zu sehr auf die Klasse ziehen, daher betrachte Diese hier nicht als mehr, als einen Bauplan für ein Werkzeug.

public class DebugLogger
{

  public DebugLogger()
  {
    
  }

  public void Log(string msg)
  {
    Debug.WriteLine($"{DateTime.Now:HH:mm:ss} {msg}");
  }

}

Public Class DebugLogger

  Sub New()
    
  End Sub

  Public Sub Log(msg As String)
    Debug.WriteLine($"{DateTime.Now:HH:mm:ss} {msg}")
  End Sub

End Class

Ein eigener Start-Prozess

Wenn ich mit heutigem Datum ein VB.NET Projekt erstelle, habe ich das Problem, dass ich – mehr oder weniger – nicht auf den Start-Prozess eingreifen kann. Es ist ohne weitere Kenntnisse nicht wirklich erkenntlich, wo das Programm eigentlich startet. Bei C# ist das schon wesentlich einfacher, bzw. auch schon für Anfänger, durch die separate „Program.cs“-Datei ersichtlicher. Wenn Du also ein C#-Projekt erstellen solltest, wird es hier einfacher und Du könntest Diese Sektion / Schritte überspringen.

Anwendungsframework deaktivieren

Begib Dich hierzu zuerst einmal in die Einstellungen Deines VB.NET-Projektes und deaktiviere das Anwendungsframework. Das ist eine Checkbox, Welche Du unter dem Reiter „Anwendung“ findest. Nur dann hatte ich bisher die Möglichkeit einen manuellen Start-Prozess zu definieren.

Beachte, dass Du diesen Menüpunkt bei modernen Projekttemplates / Visual Studio Versionen einfach via Suchleiste suchen kannst!

Manuellen Start-Prozess definieren

Bereiten wir also nun das VB.NET Windows Forms Projekt vor, damit wir hier auf einem „gleichen Stand“, wie bei einem neuen C#-Projekt sind. Erstelle analog zu einem C#-Projekt einfach eine „Program.vb“-Datei innerhalb des Wurzelverzeichnisses Deines Projekts.

Des Weiteren benötigt jede gängige Anwendung eine „Main“-Methode. Diese erstellen wir nun in einem typischen Sinne. Um unsere Anwendung dann tatsächlich starten / ausführen zu lassen, benötigen wir die „Application.Run„-Methode. Für gewöhnlich erstellt man einfach eine Instanz der jeweiligen zu anzeigenden Form und übergibt Dieser der erwähnten Run-Methode.

public class Program
{

  static void Main(string[] args)
  {
    Application.EnableVisualStyles();

    // App wird geschlossen, wenn Form1 geschlossen wird
    var frm = new Form1();
    Application.Run(frm);

    // erlaubt mehrere Formulare
    // du musst dich manuell um das Schließen der App kümmern!
    // var frm = new Form1();
    // frm.Show();
    // Application.Run();
  }

}

Public Class Program

    Public Shared Sub Main(args As String())
      Application.EnableVisualStyles()

      ' App wird geschlossen, wenn Form1 geschlossen wird
      Dim frm = New Form1()
      Application.Run(frm)

      ' erlaubt mehrere Formulare
      ' du musst dich manuell um das Schließen der App kümmern!
      ' Dim frm = New Form1()
      ' frm.Show()
      ' Application.Run()
    End Sub

End Class

Wenn Du nicht möchtest, dass sich das Programm schließt, wenn Du diese Form schließt, dann muss der Aufruf anders aussehen. Schaue Dir dazu das untere Kommentar und den dazugehörigen Code an. Schaue auch gerne in meinem Beitrag über Windows Formulare und Dialoge vorbei.

Wähle nun final die „neue“ Main-Methode in den Projekteinstellungen aus, damit Dein Programm auch tatsächlich dort loslegt. Begib Dich dazu erneut zu „Projekt->Eigenschaften->Anwendung“ und wähle bei „Startobjekt“ die jeweilige Main-Methode. Beachte, dass dies alles bei C# nicht notwendig ist, da Du eine fertige Konfiguration in der „Program.cs“ finden wirst.

Wichtiger Hinweis

Falls Du Deine Main-Methode nicht in der obigen Combobox finden kannst, habe ich eine Lösung für Dich. Beim meinem Visual Studio 2022 und dem Projekttemplate „Windows Forms Anwendung“ für .NET 6 musst ich auch kurz fummeln – aber gut.. Das macht man dann einmal und gut ist – danach weiß man es ja schließlich. Sollte leider auch nur VB.NET Projekte betreffen..

Ich gehe nun im ersten Schritt davon aus, dass Du die Main-Methode korrekt angelegt hast:

• In einer Klasse
• Public
• Shared
• Mit der typischen „args As String()“ Signatur

Falls Sie trotzdem nicht auftaucht, kannst Du das Problem manuell fixen. Mache rechts im Projektmappenexplorer einen Rechtsklick auf Dein Projekt und wähle „Projektdatei bearbeiten“ aus. Dort kannst Du Dein Startobjekt nun mit einem passenden Tag angeben.

Schreibe dazu folgendes Tag hinein:

<StartupObject>{HierDerNamespaceDeinesProgramms}.{HierDasStartobjekt}</StartupObject>

Sieht dann final wie folgt aus – bitte nur das rote Rechteck anpassen, da Du sonst Dein Projekt zerschießen könntest:

Autofac kommt in’s Spiel

Nachdem wir im vorherigen Schritt alle Vorbereitungen getroffen haben, müsste Dein Projekt jetzt den gleichen Startpunkt wie im Code hier drüber haben. Bei C# musstest Du dafür nicht wirklich etwas tun, denn dort gibt es die „Program.cs“-Datei, sprich wo alles gestartet wird, von vornherein. Bei VB.NET muss man allerdings ein wenig Konfigurationsarbeit leisten, schaue dazu in den passenden Abschnitt.

Nun können wir Autofac benutzen, um tatsächliche Abhängigkeiten – wie unseren „DebugLogger“ – zu registrieren. Dies geschieht in einer von Autofac bereitgestellten Klasse namens „ContainerBuilder“, also natürlich in einer Instanz davon. Dieser Builder erstellt uns anschließend einen fertigen, sogenannten „Container“, wenn wir die „Build“-Methode aufrufen.

Dieser beinhaltet alle notwendigen Abhängigkeiten, bzw. auch die Pläne, wie Diese erstellt werden können. Das hängt letztendlich von der Registrierungs-Art innerhalb des sogenannten DI-Containers ab. Hier gehe ich aber nicht zu tief in diesem Beitrag. Den erstellten Container müssen wir dann zwischenspeichern, damit wir später Zugriff darauf haben. In diesem Fall ist meines Erachtens nach auch ein öffentliches, statisches Feld / Eigenschaft passend.

Wir passen den Inhalt der Program-Datei also wie gleich folgend an. Beachte auch, dass nicht nur der „DebugLogger“, sondern auch die „Form1“ selbst registriert wird.

// wo die Imports halt hinkommen..
using Autofac;

// außerhalb der Main-Methode, aber innerhalb der Program-Datei
public static IContainer Container { get; set; }

// Inhalt der Main-Methode
var builder = new ContainerBuilder();
builder.RegisterType<Form1>();
builder.RegisterType<DebugLogger>();
Container = builder.Build();

' wo die Imports halt hinkommen..
Imports Autofac

' außerhalb der Main-Methode, aber innerhalb der Program-Datei
Public Shared Property Container As IContainer

' Inhalt der Main-Methode
Dim builder = new ContainerBuilder()
builder.RegisterType(Of Form1)()
builder.RegisterType(Of DebugLogger)()
Container = builder.Build()

Eine (korrekte) Abhängigkeit erschaffen

Im vorletzten Schritt müssen wir unserem Programm nun beibringen, dass die Form1 tatsächlich von unserem „DebugLogger“ abhängig ist. Anders gesprochen: ..dass unsere Form den DebugLogger benötigt, um Ihre Arbeit / Funktionlität zu erledigen.

Der wichtigste Unterschied ist nun nach all Dem, dass wir den fertigen, gleichen DebugLogger in die Form injizieren werden. Okay, um genau zu sein, tun wir dies nicht selbst, es geschieht stattdessen über den DI-Container, Welchen wir vorher durch den „ContainerBuilder“ erstellt haben.

Nun bringen wir unserer Form bei: „Hey, ich benötige den DebugLogger zur Erledigung meiner Arbeit“. Dies geschieht in den meisten Fällen über die sogenannte Konstruktor-Injektion, naja, eben weil Sie im Konstruktor stattfindet:

public class Form1
{

  // Deklaration der Abhängigkeit
  DebugLogger _logger;

  public Form1(DebugLogger logger)
  {
    InitializeComponent();
    // der logger kommt in die Instanz "hinein"
    // von nun an, kann Dieser überall wo notwendig
    // verwendet werden
    _logger = logger;
    Load += Form1_Load;
  }

  private void Form1_Load(object sender, EventArgs e)
  {
   // die erste Verwendung unseres Loggers!!
    _logger.Log("Yay, Form1_Load wurde aufgerufen!");
  }

}

Public Class Form1

  ' Deklaration der Abhängigkeit
  Private _logger As DebugLogger

  Sub New(logger As DebugLogger)
    InitializeComponent()
    ' der logger kommt in die Instanz "hinein"
    ' von nun an, kann Dieser überall wo notwendig
    ' verwendet werden
    _logger = logger
  End Sub

  Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
    ' die erste Verwendung unseres Loggers!!
    _logger.Log("Yay, Form1_Load wurde aufgerufen!")
  End Sub

End Class

Die Form richtig „auflösen“

Wichtig: Hierbei geht es nicht um eine Art Brausetablette! Auflösen bedeutet im Kontext der Dependency Injection, dass man die jeweilig definierten Abhängigkeiten aus dem Container abruft. Das Ziel-Objekt kann dann anschließend damit bestückt werden. Dazu bietet uns die Container-Instanz der Autofac-Bibliothek eine Methode namens „Resolve“ an.

Hier kannst Du nun den finalen Code mit ein wenig Refactoring sehen, beachte noch den Form-Code aus dem vorherigen Abschnitt:

using Autofac;

public class Program
{

  public static IContainer Container { get; set; }

  static void Main(string[] args)
  {
    PrepareDI();
    RunApp();
  }

  private static void PrepareDI()
  {
    var builder = new ContainerBuilder();
    builder.RegisterType<DebugLogger>();
    builder.RegisterType<Form1>();
    Container = builder.Build();
  }

  private static void RunApp()
  { 
    Application.EnableVisualStyles();
    var frm = Container.Resolve<Form1>();
    frm.Show();
    Application.Run();
  }

}

Imports Autofac

Public Class Program

    Public Shared Property Container As IContainer

    Private Shared Sub Main(args As String())
        PrepareDI()
        RunApp()
    End Sub

    Private Shared Sub PrepareDI()
        Dim builder = New ContainerBuilder()
        builder.RegisterType(Of DebugLogger)()
        builder.RegisterType(Of Form1)()
        Container = builder.Build()
    End Sub

    Private Shared Sub RunApp()
        Application.EnableVisualStyles()
        Dim frm = Container.Resolve(Of Form1)()
        frm.Show()
        Application.Run()
    End Sub

End Class

Downloads

Wie (fast) immer biete ich Dir hier den kompletten Code zum Beitrag als Download an, so kannst Du alles schnell nachbauen und testen. Ziehe Dir einfach das Projekt Deiner Wahl, ob nun VB.NET oder C#!

Der Beitrag .NET Dependency Injection (DI) mit Autofac 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.

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.

Dein VB.NET Programm automatisch bei Systemstart starten

Hast Du Deine nächste tolle Anwendung entwickelt, Welche Du nun via VB.NET in den Autostart packen möchtest? Im heutigen Beitrag schauen wir uns genau das und mehr, wie z. B. das Erstellen von Verknüpfungen via der „WshShell“ an. Bleib also dran, es wird ziemlich interessant 😉!

💡 Hinweis: Wenn Du es eilig hast, kannst Du auch direkt zum Code weiter unten scrollen, bzw. das Inhaltsverzeichnis für das Springen zu verschiedenen Eckpunkten verwenden. Auch wenn der Beitrag seinen Fokus auf VB.NET hat, sind alle Code-Beispiele natürlich auch für C# verfügbar! Springe für den kompletten Code, oder für dessen Verwendungsbeispiele nach unten.

Wie Du vielleicht weißt hatte ich auch schonmal ein Video zum Thema gemacht – vor unfassbaren 11 Jahren, oh man, ich werde alt.. Ein Abonnent hatte mich darauf aufmerksam gemacht, dass es in die Jahre gekommen ist und er sich ein Update wünscht. Dies war mir Befehl und nun sind wir hier 🤓!

Wenn Du moderne Anwendungen entwickeln möchtest – Welche dann passenderweise in den Autostart können –, solltest Du Dir unbedingt diese beiden Beiträge anschauen:

• Der ultimative INotifyPropertyChanged Guide – für C# & VB.NET
• Der ultimative WPF DataGrid MVVM Guide – C# & VB.NET

Als Video ansehen – „VB.NET Autostart von Programmen“

Wenn Du es eiliger, bzw. eventuell keine Lust auf Text hast, kannst Du natürlich auch gerne zum Videoformat greifen und Dich berieseln lassen. Nutze auch im Video gerne die Kapitel, um zu den Stellen von besonderem Interesse zu springen.

Wie startet man Software überhaupt via Autostart?

Bevor wir uns an die VB.NET-spezifische Thematik wagen, ist es ggf. vorerst ganz sinnvoll, sich mit dieser Frage auseinanderzusetzen: Wie starte ich ein Programm überhaupt bei Systemstart? Grundsätzlich ist die Antwort darauf ziemlich einfach, denn Windows bietet eigentlich alle Bordmittel, Die man als Administrator oder auch Entwickler, braucht.

Dazu gibt es den sogenannten Autostart-Ordner, Welcher ungefähr so wie gleich folgend aussieht. Bei mir ist – zugegebenermaßen – nicht viel dort zu sehen, denn ich versuche den immer „clean“ zu halten.

Vorgehensweise

Um ein Programm beim Start des Windows-Systems automatisch mit-starten zu lassen, muss man Dieses, bzw. eine Verknüpfung dazu in den Autostart-Ordner ablegen. Das Schöne ist hier wirklich die Möglichkeit der Verknüpfung, denn wer hat Lust, jedes Mal x Megabyte zu kopieren und eventuell dann doppelt zu haben. Ich persönlich hatte bei dieser Vorgehensweise auch nie Probleme, im Gegensatz zu einigen recherchierten Suchergebnissen auf Google. Kommentiere gerne, wenn auch Du auf derartige Probleme stößt, würde mich interessieren!

Vorsicht geboten

Wie erwähnt wird jedes Programm, bzw. jede Verknüpfung im genannten Ordner automatisch bei Systemstart gestartet. Das stattet uns Entwickler & Administratoren natürlich auch mit einer großen Bürde aus. Erstens – so finde ich – sollte man dem Nutzer bei Systemstart nicht direkt 20 GUIs an den Kopf schmeißen und zweitens sollte man ja auch noch an die Startzeit denken. Wer hat schon Lust, 5 Minuten länger zu warten, nur weil ein Programm bei Start schon viel Auslastung zieht!?

Welche Möglichkeiten habe ich beim Autostart?

Egal ob mit VB.NET (oder C#..), oder ohne, wir haben verschiedene Möglichkeiten, den Autostart zu verwenden. Einerseits können wir benutzerspezifische Startmöglichkeiten verwenden, oder auch global, also für alle Nutzer einen automatischen Programmstart anlegen. In diesem Beitrag gehe ich jedoch in erster Linie auf den benutzerspezifischen Autostart ein.

Wo, bzw. wie finde ich die Autostart-Ordner?

In erster Linie kommt das natürlich darauf an, für wen Du einen Autostart erstellen möchtest. Möchtest Du Dein Programm z. B. für den aktuellen Nutzer in den Autostart legen, dann kommt folgendes Verzeichnis in Frage. Beachte hierbei, dass Du den Platzhalter natürlich durch den jeweiligen Nutzernamen ersetzen müsstest:

C:\Users\<DeinNutzername>\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup

Du kannst den Ordner auch vereinfacht finden, indem Du die Windows-Taste+R drückst, was den „Ausführen“-Dialog startet. Und im nächsten Schritt dann:

shell:startup

eingeben, was Dich dann in dem für Dich passenden Autostart-Ordner auskommen lässt. Cool, oder?

Globaler Autostart-Ordner

Möchtest Du hingegen den „globalen“ Ordner finden, kannst Du stattdessen in folgendem Verzeichnis

C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

und mit diesem Befehl hier fündig werden (denke an Windows-Taste+R):

shell:common startup

Hier findest Du dann die Programme, Welche für alle Nutzer automatisch bei Systemstart gestartet werden sollen.

Wie sieht der VB.NET Autostart nun aus?

Um nun die oben erklärte Logik, bzw. Vorgehensweise mit VB.NET nachzubilden, müssen wir ja praktisch nichts Anderes tun. Wir müssen (via Code) eine Verknüpfung unserer Anwendung erschaffen und Diese nach Möglichkeit im Autostart-Ordner unserer Wahl unterbringen. Besonders die Erstellung einer Verknüpfung kann aber tricky sein, wenn man nicht weiß, wie.

Zusätzlich könnte man weitere Hilfsmittel schreiben, um z. B. überprüfen zu können, ob sich unsere Anwendung aktuell schon im Autostart befindet. Dies alles werden wir selbstverständlich nach Regeln der OOP (Objektorientierten Programmierung) in eine Klasse auslagern. So bleibt alles schön wiederverwendbar und portierbar.

Lege also im nächsten Schritt einen Ordner namens „Utils“ in Deinem Projekt an und erstelle dort drin eine „Autostart“-Klasse.

Mit VB.NET den Autostart-Ordner ermitteln

Bevor wir uns jedoch Gedanken über Dinge wie „Wie kann ich die Verknüpfung erstellen“, usw. machen, starten wir easy. Zuerst einmal müssen wir wissen, wie wir an den Autostart-Ordner kommen, ist ja schließlich Betriebssystem-Sache. Zufälligerweise benutzen wir eine optimale Sprache für dieses Betriebssystem vom selben Hersteller – kann ja dann nicht so schwer sein, richtig? Richtig!

Um an den Pfad zum Autostart-Ordner (auch Startup-Folder genannt) zu kommen, können wir vorgefertigte Funktionen nutzen. Die Methode unseres Vertrauens befindet sich in der „Environment“-Klasse und heißt „GetFolderPath“. Diese erwartet einen Wert der „SpecialFolder“-Enumeration aus selbiger Klasse.

Implementieren wir nun eine Art „Singleton“-, bzw. eine „Lazy“-Property (Eigenschaft), Welche uns den Autostart-Ordner serviert. So müssen wir der Environment nicht öfter als nötig auf die Nerven gehen – ergo, die Funktion nur einmalig aufrufen und den Rückgabewert zwischenspeichern:

        Private Shared _startupDirectory As String

        Public Shared ReadOnly Property StartupDirectory As String
            Get
                If String.IsNullOrWhiteSpace(_startupDirectory) Then
                    _startupDirectory = Environment.GetFolderPath(Environment.SpecialFolder.Startup)
                End If
                Return _startupDirectory
            End Get
        End Property

    private static string _startupDirectory;

    public static string StartupDirectory
    {
        get
        {
            if (string.IsNullOrWhiteSpace(_startupDirectory))
                _startupDirectory = Environment.GetFolderPath(Environment.SpecialFolder.Startup);
            return _startupDirectory;
        }
    }

Einen Eintrag in den Autostart mit VB.NET hinzufügen

Im nächsten Schritt schauen wir uns an, wie wir unsere VB.NET-Anwendung, bzw. eine Verknüpfung davon in den Autostart-Ordner gelegt bekommen. Dazu bauen wir uns eine kleine „AddEntry“ Methode, Welcher es egal ist, ob ein Pfad zu unserer Anwendung mitkommt, denn Diesen, kann Sie auch selbst ermitteln. So bleibt uns die Möglichkeit übrig, fremde Anwendungen, sowie die Eigene gemütlich hinzuzufügen:

        ''' <summary>
        ''' Adds an entry to the autostart folder for the given Application
        ''' </summary>
        ''' <param name="applicationFilePath">The given application filepath, or empty to create an autostart for the current executing .exe</param>
        Public Shared Sub AddEntry(Optional applicationFilePath As String = "")
            Dim noAppPathProvided = applicationFilePath = ""
            If noAppPathProvided Then
                DefaultToExecutingExe(applicationFilePath)
            End If
            CreateShortcut(applicationFilePath)
        End Sub

/// <summary>
/// Adds an entry to the autostart folder for the given Application
/// </summary>
/// <param name="applicationFilePath">The given application filepath, or empty to create an autostart for the currently executing .exe</param>
public static void AddEntry(string applicationFilePath = "")
{
    var noAppPathProvided = applicationFilePath == "";
    if (noAppPathProvided)
        DefaultToExecutingExe(applicationFilePath);
    CreateShortcut(applicationFilePath);
}

Wie Du hier schon sehen kannst, schauen wir (wie erwähnt), ob ein passender „applicationFilePath“ mitgeliefert wurde. Wenn nicht „Defaulten“ wir zur ausführenden Exe-Datei, also dem aktuellen Programm. So oder so erstellen wir am Ende der Methode eine Verknüpfung, was wir im nächsten Schritt besprechen werden.

Die ausgeführte .Exe-Datei erkennen

Nachdem wir die eigentliche Methode schon einmal im letzten Schritt vorbereitet haben, fehlen nun noch die 2 Sub-Routinen. In erster Linie schauen wir hier uns hier schnell die „DefaultToExecutingExe“-Methode an. Diese bekommt einen „ByRef“-Parameter übergeben – empfand ich hier irgendwie leichter lesbar – aber ist nur meine Meinung. Diese setzt dann den „applicationFilePath“ via „Process“-Klasse, bzw. mittels einer verschachtelten Sub-Eigenschaft des Prozesses. Diesen ermitteln wir mit der statischen „GetCurrentProcess“-Funktion der „Process“-Klasse. Hier gibt es ab .NET 6 auch eine neue Variante, allerdings habe ich hier Die genommen, Welche vermutlich am geläufigsten ist.

Unsere VB.NET Anwendung als Verknüpfung in den Autostart legen

Nun fehlt nur noch ein letztes Werkzeug, die Funktionalität, für unsere (und auch andere Anwendungen) eine Verknüpfung erzeugen zu können. Dies kann – wie oben bereits erwähnt – ein wenig tricky werden, wenn man nicht weiß, wie. Wir verwenden dazu das „WshShell“-Interface, Welches komischerweise instanziiert werden kann, Du glaubst mir nicht? Guck in den Code!

COM-Verweis hinzufügen

Bevor wir damit jedoch starten können, müssen wir zuerst noch den benötigten COM-Verweis auf das „Windows Script Host Object Model“ hinzufügen. Das kannst Du ganz einfach machen, indem Du einen Rechtsklick auf Dein Projekt durchführst und anschließend „Hinzufügen->COM-Verweis“ auswählst.

Danach erscheint dieses folgende Fenster, wo Du dann oben rechts dementsprechend z. B. nach „host“ suchen kannst, dann dürftest Du – siehe Bild – schnell fündig werden:

Ein instanziierbares Interface – what the f**?

Um ehrlich zu sein – wie ich nunmal bin.. – habe ich mich selbst damit auch nicht auseinandergesetzt, warum man diese Schnittstelle instanziieren kann (auch in C#). Und da ich COM-Dinge eigentlich nie benötige, ist mir das hier auch relativ egal, solange es funktioniert. Ich gehe mal ohne Recherche davon aus, dass das an der Deklaration des Interfaces liegt, dort sehen wir ein „CoClass“-Attribut.

Vermutlich wird „der Code“ dann sehen: „Ah, da ist ein CoClass Ding, also muss ich das wohl instaziieren“ – oder so ähnlich. EDIT: Habe kurz nachgeguckt, liegt wie vermutet an dem „CoClass“-Attribut – Erfahrung „strikes again“ 😉!

Eine Verknüpfung erstellen

Nachdem wir das Interface nun instanziieren können – ew, klingt immer noch ekelig, na egal – tun wir gleich genau das. Vorher erstellen wir noch ein „FileInfo“-Objekt, Welches uns bei der Arbeit mit Datei-Infos wie den Namen der Datei, usw. unterstützen wird. Und dann gehen wir schonmal hin und erstellen den letztendlichen Pfad der Verknüpfung mit String-Interpolation.

Hier verwenden wir ein weiteres kleines Helferlein, was – wie der Name schon sagt – den Dateinamen ohne Dateiendung für uns herausfiltert. Dazu übergeben wir der statischen „Path“-Klassen-Funktion „GetFileNameWithoutExtension“, den Namen des „FileInfo“-Objektes.

Im letzten Schritt erzeugen wir die Verknüpfung auf Objekt-Ebene und casten Sie in ein für unsere Zwecke passendes Interface – „IWshShortcut“. Anschließend kannst Du weitere Eigenschaften wie z. B. die Beschreibung und den Icon-Pfad angeben, dies lasse ich hier aber aus. Zuletzt kommen die beiden wichtigsten Schritte: Den Ziel-Pfad, also den Pfad zur eigentlichen Anwendung festzulegen und dann final auch „Save“ aufzurufen, damit die Verknüpfung tatsächlich erstellt wird.

Prüfen ob ein Autostart-Eintrag existiert

Nun haben wir die Funktionalität von oben vorliegen und würden direkt mit der Nächsten starten. Es wäre schließlich ganz nützlich, wenn man auch prüfen könnte, ob bereits eine Verknüpfung im Autostart ist. Dazu erstellen wir im nächsten Schritt eine „EntryExists“-Funktion, Welche dies über einen Boolean kommuniziert.

In den ersten Zeilen verfahren wir hier wir in der „AddEntry“-Methode, also bezogen auf die Pfad-Sache. Wenn kein Pfad angegeben wurde, nehmen wir den Pfad der aktuellen Exe-Datei, usw. Danach bauen wir uns den Pfad zur Verknüpfung (im Autostart-Ordner!) zusammen. Wenn eine derartige Datei (dort) existiert, dann haben wir das Programm bereits im Autostart – yay!

        Public Shared Function EntryExists(Optional applicationFilePath As String = "") As Boolean
            Dim noAppPathProvided = applicationFilePath = ""
            If noAppPathProvided Then
                DefaultToExecutingExe(applicationFilePath)
            End If
            Dim applicationFile = New FileInfo(applicationFilePath)
            Dim shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk")
            Return IO.File.Exists(shortcutPath)
        End Function

public static bool EntryExists(string applicationFilePath = "")
{
    var noAppPathProvided = applicationFilePath == "";
    if (noAppPathProvided)
        DefaultToExecutingExe(applicationFilePath);
    var applicationFile = new FileInfo(applicationFilePath);
    var shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk");
    return System.IO.File.Exists(shortcutPath);
}

Mit VB.NET den Autostart wieder entfernen

Im letzten Abschnitt dieses Beitrages werden wir uns ansehen, wie wir erzeugte Einträge auch wieder entfernen können. Dies kennt man natürlich bereits aus größeren Tools. Wir schreiben also eine „RemoveEntry“-Methode, Welche sehr ähnlich zu den Vorherigen funktioniert. Zuerst prüfen wir wieder die Pfad-Übergabe, danach erstellen wir der Einfachheit halber eine „FileInfo“ und danach generieren wir den Verknüpfungs-Pfad.

Wenn Dieser Pfad existent ist, wird er gelöscht, somit wird auch unser VB.NET Autostart entfernt. Beachte hierbei, dass ich bewusst kein Try-Catch drum gemacht habe. Ich möchte aktiv auf Fehler reagieren und diese separat und sauber verarbeiten können.

Kompletter Code

Hier findest Du den wichtigsten Code für diesen Beitrag. In diesem Beispiel handelt es sich um die kleine von mir gebaute Hilfs-Klasse. Diese vereinfacht Dir die Erstellung der Programm-Verknüpfung innerhalb des Autostart-Ordners via VB.NET (und C#!):

Imports System.IO
Imports IWshRuntimeLibrary

Namespace Utils

    Public Class Autostart

        Private Shared _startupDirectory As String

        Public Shared ReadOnly Property StartupDirectory As String
            Get
                If String.IsNullOrWhiteSpace(_startupDirectory) Then
                    _startupDirectory = Environment.GetFolderPath(Environment.SpecialFolder.Startup)
                End If
                Return _startupDirectory
            End Get
        End Property

        ''' <summary>
        ''' Adds an entry to the autostart folder for the given Application
        ''' </summary>
        ''' <param name="applicationFilePath">The given application filepath, or empty to create an autostart for the current executing .exe</param>
        Public Shared Sub AddEntry(Optional applicationFilePath As String = "")
            Dim noAppPathProvided = applicationFilePath = ""
            If noAppPathProvided Then
                DefaultToExecutingExe(applicationFilePath)
            End If
            CreateShortcut(applicationFilePath)
        End Sub

        Private Shared Sub DefaultToExecutingExe(ByRef applicationFilePath As String)
            applicationFilePath = Process.GetCurrentProcess().MainModule.FileName
        End Sub

        Private Shared Sub CreateShortcut(applicationFilePath As String)
            Dim applicationFile = New FileInfo(applicationFilePath)
            Dim shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk")
            Dim shell = New WshShell()
            Dim shortcut = CType(shell.CreateShortcut(shortcutPath), IWshShortcut)
            With shortcut
                ' .Description = ""
                ' .IconLocation = ""
                .TargetPath = applicationFile.FullName
                .Save()
            End With
        End Sub

        Public Shared Function EntryExists(Optional applicationFilePath As String = "") As Boolean
            Dim noAppPathProvided = applicationFilePath = ""
            If noAppPathProvided Then
                DefaultToExecutingExe(applicationFilePath)
            End If
            Dim applicationFile = New FileInfo(applicationFilePath)
            Dim shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk")
            Return IO.File.Exists(shortcutPath)
        End Function

        Public Shared Sub RemoveEntry(Optional applicationFilePath As String = "")
            Dim noAppPathProvided = applicationFilePath = ""
            If noAppPathProvided Then
                DefaultToExecutingExe(applicationFilePath)
            End If
            Dim applicationFile = New FileInfo(applicationFilePath)
            Dim shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk")
            IO.File.Delete(shortcutPath)
        End Sub

    End Class

End Namespace

using System.IO;
using IWshRuntimeLibrary;

namespace Utils
{
    public class Autostart
    {
        private static string _startupDirectory;

        public static string StartupDirectory
        {
            get
            {
                if (string.IsNullOrWhiteSpace(_startupDirectory))
                    _startupDirectory = Environment.GetFolderPath(Environment.SpecialFolder.Startup);
                return _startupDirectory;
            }
        }

        /// <summary>
        ///         ''' Adds an entry to the autostart folder for the given Application
        ///         ''' </summary>
        ///         ''' <param name="applicationFilePath">The given application filepath, or empty to create an autostart for the current executing .exe</param>
        public static void AddEntry(string applicationFilePath = "")
        {
            var noAppPathProvided = applicationFilePath == "";
            if (noAppPathProvided)
                DefaultToExecutingExe(ref applicationFilePath);
            CreateShortcut(applicationFilePath);
        }

        private static void DefaultToExecutingExe(ref string applicationFilePath)
        {
            applicationFilePath = Process.GetCurrentProcess().MainModule.FileName;
        }

        private static void CreateShortcut(string applicationFilePath)
        {
            var applicationFile = new FileInfo(applicationFilePath);
            var shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk");
            var shell = new WshShell();
            var shortcut = (IWshShortcut)shell.CreateShortcut(shortcutPath);
            {
                var withBlock = shortcut;
                // .Description = ""
                // .IconLocation = ""
                withBlock.TargetPath = applicationFile.FullName;
                withBlock.Save();
            }
        }

        public static bool EntryExists(string applicationFilePath = "")
        {
            var noAppPathProvided = applicationFilePath == "";
            if (noAppPathProvided)
                DefaultToExecutingExe(ref applicationFilePath);
            var applicationFile = new FileInfo(applicationFilePath);
            var shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk");
            return System.IO.File.Exists(shortcutPath);
        }

        public static void RemoveEntry(string applicationFilePath = "")
        {
            var noAppPathProvided = applicationFilePath == "";
            if (noAppPathProvided)
                DefaultToExecutingExe(ref applicationFilePath);
            var applicationFile = new FileInfo(applicationFilePath);
            var shortcutPath = Path.Combine(StartupDirectory, $"{Path.GetFileNameWithoutExtension(applicationFile.Name)}.lnk");
            System.IO.File.Delete(shortcutPath);
        }
    }
}

Verwendung des Codes

Um den obigen Code verwenden zu können, kannst Du z. B. 2 Knöpfe und eine CheckBox in Deine Form setzen. Beim Start des Formulares wird die Checkbox je nachdem ob das VB.NET Programm im Autostart liegt gefüllt. Wenn Du dann auf die jeweiligen Buttons drückst, kannst Du das Programm wieder aus dem Autostart entfernen, bzw. natürlich auch hinzufügen. Die Namen sind denke ich selbsterklärend..

Imports AutoStartExampleVb.Utils

Public Class Form1

    Private Sub Form1_Load(sender As Object, e As EventArgs) Handles MyBase.Load
        chbAutostartActivated.Checked = Autostart.EntryExists()
    End Sub

    Private Sub btnActivateAutostart_Click(sender As Object, e As EventArgs) Handles btnActivateAutostart.Click
        Autostart.AddEntry()
        chbAutostartActivated.Checked = True
    End Sub

    Private Sub btnDeactivateAutostart_Click(sender As Object, e As EventArgs) Handles btnDeactivateAutostart.Click
        Autostart.RemoveEntry()
        chbAutostartActivated.Checked = False
    End Sub

End Class

using System;
using AutoStartExampleVb.Utils;

public class Form1
{
    private void Form1_Load(object sender, EventArgs e)
    {
        chbAutostartActivated.Checked = Autostart.EntryExists();
    }

    private void btnActivateAutostart_Click(object sender, EventArgs e)
    {
        Autostart.AddEntry();
        chbAutostartActivated.Checked = true;
    }

    private void btnDeactivateAutostart_Click(object sender, EventArgs e)
    {
        Autostart.RemoveEntry();
        chbAutostartActivated.Checked = false;
    }
}

Downloads

Keine Lust alles zu kopieren und es manuell zusammen zu frickeln? Dann lade Dir hier einfach den Beispielcode herunter, Dieser beinhaltet die komplette und fertig testbare Projektmappe.

Der Beitrag VB.NET Autostart für Dein eigenes Programm erstellen – 2024 Version 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.

Datenbindungs-Änderungen einfach ans UI weiterleiten

Kennst Du auch das Problem, die „INotifyPropertyChanged“-Schnittstelle immer wieder implementieren zu müssen? Egal ob in VB.NET oder C#, jedes ViewModel benötigt in guter alter „WPF MVVM“-Manier dieses implementierte Interface, um Änderungen der Daten an die Oberfläche bekanntzugeben. Nervig wird es dann nur, wenn man das Gefühl hat, endlose Monkey-Work zu schreiben, aber zum Glück gibt es die Vererbung, gell!?

💡 Du hast es eilig?: Kein Problem, navigiere einfach mithilfe des Inhaltsverzeichnisses an für Dich wichtige Punkte. Natürlich kannst Du Dich auch durch das Video berieseln lassen. Im Beitrag gehe ich allerdings mehr auf die Details und mehr Hintergründe ein – ggf. nimmst Du Ihn daher als Ergänzung.

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

public abstract class PropertyChangedBase : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler? PropertyChanged;

    protected void NotifyOfPropertyChange([CallerMemberName] string? propertyName = null)
        => PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(propertyName));
}

Imports System.ComponentModel
Imports System.Runtime.CompilerServices

Public MustInherit Class PropertyChangedBase
    Implements INotifyPropertyChanged

    Public Event PropertyChanged As PropertyChangedEventHandler _
        Implements INotifyPropertyChanged.PropertyChanged

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

public class MainViewModel : PropertyChangedBase
{
    private string _name = string.Empty;

    public string Name
    {
        get => _name;
        set
        {
            if (_name == value) return;
            _name = value;
            NotifyOfPropertyChange();
        }
    }
}

Public Class MainViewModel
    Inherits PropertyChangedBase

    Private _name As String = String.Empty

    Public Property Name As String
        Get
            Return _name
        End Get
        Set(value As String)
            If _name = value Then Return
            _name = value
            NotifyOfPropertyChange()
        End Set
    End Property
End Class

<TextBlock Text="{Binding Name}" />
<TextBox Text="{Binding Name, UpdateSourceTrigger=PropertyChanged}" />

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

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

Mithilfe von Vererbung werden wir uns heute ein kleines Helferlein, Welches einem die tägliche Arbeit im Bereich Datenbindungen vereinfachen kann, erstellen. In einem folgenden Beitrag werde ich hier auch noch einen Schritt weiter optimieren, das darfst Du auf keinen Fall verpassen – dort reduzieren wir alles auf eine einzige Zeile 😉. Ich meine, wer hat schon Bock alles 50x zu schreiben!?

Bevor wir damit jedoch starten, machen wir erst einmal eine Reise zurück, also zur Basis von INotifyPropertyChanged.

Zu viel Text? Schaue das Video!

Wenn Du keine Lust hast, diesen Beitrag in schriftlicher Form durchzuarbeiten, kannst Du Dir natürlich auch das Video zu Gemüte führen.

Was ist INotifyPropertyChanged?

Wie oben bereits erwähnt, gehen wir erst einmal einen Schritt zurück, bevor wir weiter nach vorn gehen. Man muss ja schließlich erstmal die Basics dahinter verstehen, bevor man dann auf Diesen aufbauen kann. Wie man zumindest schonmal an dem für .NET Schnittstellen typischen „I“-Prefix erkennen kann, handelt es sich bei „INotifyPropertyChanged“ um eine Schnittstelle (engl. Interface).

Exkurs Schnittstellen

Ohne zu tief in die Thematik Schnittstellen einzutauchen, könnte man sagen: „Schnittstellen definieren grobes Verhalten, Eigenschaften und auch Ereignisse, ohne Diese konkret zu implementieren“. Wenn man einen Menschen mit Interfaces beschreiben wollen würde, könnte man vereinfacht z. B. wie folgt beginnen:

• „ICanWalk“
• „IHaveBladder“
• „ICanSpeak“

Damit würden wir genau das tun, was Schnittstellen ausmacht: Beschreiben, was das jeweilige Objekt können wird (sogar muss). Wir wissen nun, dass ein Objekt, Welches diese Schnittstellen implementieren würde, laufen, sprechen und auf Toilette gehen können muss (eine Blase hat..). Im nächsten Schritt, könnte ich mir also bei der Verwendung eines dieser Objekte sicher sein, dass es sprechen kann. Ich weiß zwar nicht wie dieses „Ding“ spricht, aber ich kann mir sicher sein, dass es dies anbietet.

Reine Abstraktion – Nichts Konkretes

Wo wir beim nächsten wichtigen Punkt wären: Wir wissen nicht, wie der oder diejenige spricht! Die eine Person könnte eventuell nuscheln oder ggf. stottern. Der nächste könnte zum Beispiel in jedem zweiten Satz „Hm..“ sagen – wobei mich das an meine Videos erinnert (Spaß beiseite).

Okay, ich meine, wir könnten dies natürlich auch anders designen- wir sind ja schließlich die Programmierer. Wir könnten z. B. das „ICanSpeak“ nochmal genauer konkretisieren – aber dies ist eine Design-, Erfahrungs- und Anforderungssache! Unser „ICanSpeak“ könnte dann z. B. „ISpeakStutterly“ o. ä. heißen. Somit würde vielleicht eine andere Person, die auf stotternde Menschen spezialisiert ist, schauen: „Okay, wer von allen Menschen die ich hier vorliegen habe, stottern? Wem kann ich mit meiner speziellen Expertise helfen?“.

Quasi unendlich Möglichkeiten

Wenn man dies nun weiter spinnt, könnte man auch über eine dritte Instanz nachdenken, die „ISpeakStutterly – Stotterer“ und „IHelpStutterer“ gezielt zusammenbringt. Aber ich denke das reicht an dieser Stelle, sonst tauchen wir viel zu tief in die Interface-Thematik ab.

Wofür ist INotifyPropertyChanged?

Nachdem wir oben nun eine kleine Erinnerung an die Thematik „Schnittstellen“ ins Gedächtnis gerufen haben, nun zum „INotifyPropertyChanged“-Interface selbst. Grundsätzlich ist die „INotifyPropertyChanged“-Schnittstelle dazu da, der Oberfläche signalisieren zu können: „Hey, hier hat sich etwas geändert, bitte reagiere entsprechend darauf!“. Dies kann man grob und einfach definieren, WPF guckt bei einer Datenbindung: „Okay, immer wenn xy sich ändert, muss ich die Oberfläche neu zeichnen, bzw. die Darstellung aktualisieren“.

Das Problem – keine Kristallkugel!

Da weder Du noch ich z. B. voraussagen können, was der jeweils Andere in Zukunft realisieren wird, wird Dir auffallen, dass auch das .NET-Team vor diesem Problem stand. Sie konnten weder wissen, dass ich eine Transportsoftware baue (und vor allem nicht, wie ich Diese objekt-logisch-technisch gestalten würde), noch, dass Du z. B. eine rein hypothetische Lern-Software baust.

Doch kein Problem?

Das Gute ist allerdings, dass das .NET-Team das auch gar nicht wissen, oder gar hellsehen musste. Alles was wir zusammenfassen können, könnten wir mit einem groben „Verhalten“ festhalten: „Wenn sich was ändert, muss gesagt werden, was sich geändert hat“ – mehr nicht. Genau dort greift letztendlich das „INotifyPropertyChanged“-Interface und füllt die Lücke!

Wie verwendet man INotifyPropertyChanged dann?

Um dies zu erklären, packe ich mal wieder meine überaus heftigen (#ironieaus) Paint-Skills aus. Schaue Dir einmal die Parteien/Teilnehmer im Bild hier drüber an, dort habe ich es vereinfacht dargestellt.

Aus dem realen Leben

Stell Dir vor, Du bietest über einen bekannten Online-Marktplatz einen Artikel zum Verkauf an. Nun findet ein Nutzer Deinen Artikel und er kauft Diesen auch. Aber was nun? Du musst den Artikel natürlich verschicken und hierzu gibst Du die Sendungsverfolgung an – Du beobachtest also anschließend (mehr oder weniger), was der Versanddienstleister Dir mitteilt.

Auf unser Beispiel bezogen, bist Du jetzt praktisch die agierende und die zuhörende Partei in Einem – in der Praxis wäre dies getrennt, aber aktuell egal. Du bekommst von den modernen Marktplätzen das verdiente Geld heutzutage nur ausgezahlt, wenn der Versanddienstleister die Zustellung des Paketes bestätigt. Ohne den signalisierenden Dienstleister würde der Marktplatz also nie Wind davon bekommen, dass das Paket angekommen ist.

Nochmal auf MVVM bezogen

Wie oben erwähnt, vermischten sich zumindest in diesem Beispiel verschiedene Rollen. Daher werde ich dies nun auf das Model-View-ViewModel-Entwurfsmuster übertragen. Also das, was man gängigerweise in der Entwicklung mit WPF und XAML verwendet.

INotifyPropertyChanged in WPF – vollständiges MVVM Beispiel

Hierzu steigen wir nun in den Code ein und erstellen ein reelles Beispiel. Im allerersten Schritt kannst Du dafür einfach ein WPF-Projekt (egal ob C# oder VB.NET) aufsetzen. Wenn Du dies getan hast, kannst Du nun einen Ordner namens „ViewModels“ im Projekt anlegen.

Das MainViewModel erstellen

Erstelle im angelegten Ordner eine Datei namens „MainViewModel“ und befülle Sie mit dem gleichen folgenden Code. Beachte hier, dass wir nicht ganz MVVM-konform sind, da ich hier keine Art Container namens „ShellView“ erzeuge und auch das „MainWindow“ nicht wirklich umbenenne (z. B. in MainView). Ich möchte den Fokus hier wirklich nur auf das Notwendigste halten.

Namespace ViewModels

    Public Class MainViewModel

        Public Property FirstName As String

        Sub New()
            FirstName = "Robert"
        End Sub

    End Class

End Namespace

namespace ViewModels
{
    public class MainViewModel
    {
        public string FirstName { get; set; }

        public MainViewModel()
        {
            FirstName = "Robert";
        }
    }
}

Den DataContext des Views setzen

Wir arbeiten an dieser Stelle wirklich nur mit den Bordmitteln und verzichten daher auf Zusatz-Frameworks wie „Caliburn.Micro“. Daher müssen wir uns auch selbst darum kümmern, dass das View ein passendenes ViewModel gesetzt bekommt. Dies erledigen wir in diesem Beispiel (sonst nach Präferenz) in der „Code behind“-Datei. Öffne dazu einfach das „MainWindow“, sodass Du den XAML-Code siehst und drücke F7. Dies sollte dann der (einzige) Code im View-Code sein:

' HIER DEINEN PROJEKTNAMEN/BASE-NAMESPACE EINTRAGEN!
Imports <YOURPROJECTNAME>.ViewModels

Class MainWindow

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

End Class

using <YOURPROJECTNAME>.ViewModels;

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

Eine erste Darstellung

Um nun die Eigenschaft namens „FirstName“ aus dem „MainViewModel“ tatsächlich im „MainWindow“ darstellen zu können, müssen wir einfach eine für WPF übliche Datenbindung verwenden. Erstelle im MainWindow also gerne einen Textblock und wende die Datenbindung wie folgt an. Beachte, dass Du in der Zeile mit dem „:local“ Deinen Projektnamen verwendest und das „YOURPROJECTNAME“ ersetzt!

<Window x:Class="MainWindow"
        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:YOURPROJECTNAME"
        mc:Ignorable="d"
        Title="MainWindow" Height="450" Width="800" WindowStartupLocation="CenterScreen">
    <Grid>

        <StackPanel VerticalAlignment="Center" HorizontalAlignment="Center">
            <TextBlock Text="{Binding FirstName}" />
        </StackPanel>

    </Grid>
</Window>

Das daraus resultierende Ergebnis kannst Du hier sehen (ich weiß, noch nicht wirklich interessant, aber hier geht es ja nicht um’s Design):

Was, wenn sich etwas ändert?

Nachdem Du im letzten Schritt das Basic-MVVM-Beispiel erstellt hast, können wir uns nun weiter an das „INotifyPropertyChanged“-Interface selbst herantasten. Dazu zeige ich Dir eine kleine Demonstration, Welche alles noch weiter verdeutlichen wird. Außerdem ändern wir im nächsten Schritt den Inhalt der „FirstName“-Eigenschaft im ViewModel.

Lass‘ uns nun einmal folgende Methode im MainViewModel definieren, beachte jedoch, dass ich dies hier nur als Demonstration des eigentlichen Anliegens mache. Man sollte keine Async Subs/Voids verwenden, da man damit Probleme mit der sogenannten „Statemachine“, bzw. dem „Exception-Stack“ erzeugt – aber.. anderes Thema.

Natürlich müssen wir die Methode auch aufrufen, sonst passiert schließlich nicht viel – dies tue ich im Konstruktor. Ca. 2 Sekunden nach der Ausführung des Programmes sollte sich nun die „FirstName“-Eigenschaft im ViewModel ändern, tut Sie aber scheinbar nicht – doch, tut Sie wohl 😉! Setze gerne einen Haltepunkt, wenn Du mir nicht glaubst, die Zeile wird ausgeführt!

' .... MainViewModel

Sub New()
    FirstName = "Robert"
    ChangeAfterSeconds()
End Sub

Private Async Sub ChangeAfterSeconds()
    Await Task.Delay(2000)
    FirstName = "Hans"
End Sub

' ....

// .... MainViewModel

public MainViewModel()
{
    FirstName = "Robert";
    ChangeAfterSeconds();
}

private async void ChangeAfterSeconds()
{
    await Task.Delay(2000);
    FirstName = "Hans";
}

// ....

Warum wird die Änderung nicht angezeigt?

Nun – woah – nachdem wir nun einige Basics wie die groben Zwecke von Interfaces und vielen anderen Dingen wiederholt haben, kommen wir (endlich, sorry) zum Punkt! Das View kennt zwar nun das zu sich passende ViewModel – genauer gesagt, den gesetzten DataContext, Welcher eine Instanz des MainViewModels ist. Es bekommt allerdings ohne weitere Hilfe nichts von den Änderungen an einer jeweiligen Eigenschaft mit.

Dies lösen wir nun mit dem INotifyPropertyChanged Interface!

Eine INotifyPropertyChanged Implementierung

Wie Du im letzten Abschnitt gesehen hast, hat sich die „FirstName“-Eigenschaft trotz Ausführung der Zeile augenscheinlich nicht geändert. Wir haben aber durch z. B. Einzelschritt-Debugging feststellen können, dass Diese sich sehr wohl ändert, jedoch eine Benachrichtigung darüber an die UI fehlt. Diese werden wir nun mit einer „INotifyPropertyChanged“-Implementierung realisieren.

Das PropertyChanged-Ereignis

Schreibe dazu einfach unter den Namen Deiner Klasse „Implements INotifyPropertyChanged“ und bestätige die Importierung des „System.ComponentModel“-Namespaces. Dann sollte auch direkt das „PropertyChanged“-Ereignis eingebunden werden. Und ja, was soll ich sagen, dies ist es, worum es im Kern geht!

Nach Ausführung der Auto-Vervollständigung sieht unser MainViewModel nun ungefähr so aus:

Imports System.ComponentModel

Namespace ViewModels

    Public Class MainViewModel
        Implements INotifyPropertyChanged

        Public Property FirstName As String

        Sub New()
            FirstName = "Robert"
            ChangeAfterSeconds()
        End Sub

        Private Async Sub ChangeAfterSeconds()
            Await Task.Delay(2000)
            FirstName = "Hans"
        End Sub

        Public Event PropertyChanged As PropertyChangedEventHandler Implements INotifyPropertyChanged.PropertyChanged

    End Class

End Namespace

using System.Threading.Tasks;
using System.ComponentModel;

namespace ViewModels
{
    public class MainViewModel : INotifyPropertyChanged
    {
        public string FirstName { get; set; }

        public DummyViewModel()
        {
            FirstName = "Robert";
            ChangeAfterSeconds();
        }

        private async void ChangeAfterSeconds()
        {
            await Task.Delay(2000);
            FirstName = "Hans";
        }

        public event PropertyChangedEventHandler PropertyChanged;
    }
}

Aber dennoch passiert irgendwie nichts? Ich kann mir schon Deine Gedanken vorstellen: „Aber Robert, Du hast doch gesagt, dass das dann geht.. :/“. Geduld junger Padawan, es bringt natürlich nichts, das Ereignis nur zu deklarieren, wir müssen es ja schließlich auch zur passenden Zeit auslösen!

Das Ereignis auslösen

Um nun eine Änderung von „FirstName“ an die Datenbindung der grafischen Oberfläche zu kommunizieren, müssen wir das „PropertyChanged“-Ereignis mit entsprechenden Daten auslösen. Wir haben mit dem Ereignis die Möglichkeit mitzuteilen, welche Eigenschaft sich geändert hat. Um nun zu sagen, dass sich „FirstName“ geändert hat, können wir es an passender Stelle so machen:

' ... MainViewModel
FirstName = "Hans"
RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(NameOf(FirstName)))
' ...

// ... MainViewModel
FirstName = "Hans";
PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(FirstName)));
// ...

💡Hinweis: Beachte, dass ich hier den NameOf-Ausdruck verwende, Dieser hilft mir mit Compiler-Unterstützung, die korrekten namen der Variablen/Eigenschaften zu verwenden. So kann ich nicht aus Versehen „FirstNamee“ schreiben, ohne das ich es merke!

Nun können wir die Änderung tatsächlich (endlich) im View sehen. Bedenke hierbei auch, dass Du diese Vorgehensweise für sämtliche Eigenschaften verwenden kann! Booleans, Strings, oder komplexe Objekte, Du sagst hier schließlich nur „xy hat sich geändert“ – wer das dann wie rendert (z. B. mit einem DataTemplate), ist eine andere Sache!

Verbesserung 1 – Zentralisierung

Sicherlich kannst Du Dir jetzt schon denken, dass es ziemlich anstrengend sein kann, wenn Du nun überall, wo Du die „FirstName“-Eigenschaft änderst, das Ereignis auslösen musst. Keine Sorge, musst Du nicht, Du kannst es schließlich durch eine manuell implementierte Eigenschaft (statt der Automatischen) zentralisieren. Wir können also folgendes formulieren: „Immer wenn die Eigenschaft gesetzt wird *hust, Setter, hust*, dann müssen wir PropertyChanged auslösen“.

💡Hinweis: In einem der nächsten Beiträge werde ich erklären, wie man auch dies wesentlich einfacher gestalten kann, allerdings bleibt einem ohne weitere Hilfe erstmal nichts Anderes übrig!

Dies könnte so aussehen:

' ... MainViewModel
Private _firstName As String

Public Property FirstName As String
    Get
        Return _firstName
    End Get
    Set (value as String)
        ' nur wenn sich wirklich was geändert hat..
        If _firstName = value Then
            Return
        End If
        ' .. sagen, dass sich was geändert hat!
        _firstName = value
        RaiseEvent PropertyChanged(Me, New PropertyChangedEventArgs(NameOf(FirstName)))
    End Set
End Property
' ...

// ... MainViewModel
    private string _firstName;

    public string FirstName
    {
        get
        {
            return _firstName;
        }
        set
        {
            // nur wenn sich wirklich was geändert hat..
            if (_firstName == value)
                return;
            // .. sagen, dass sich was geändert hat!
            _firstName = value;
            PropertyChanged?.Invoke(this, new PropertyChangedEventArgs(nameof(FirstName)));
        }
    }
// ...

Nun kann die Eigenschaft ruhig aus verschiedenen Quellen gesetzt werden und trotzdem haben wir nur an einer zentralen Stelle die Auslösung des „PropertyChanged“-Ereignisses.

Verbesserung 2 – Vererbung der Funktionalität

Du kannst Dir nun sicherlich vorstellen, Welchen Aufwand wir haben, wenn wir (wie für die meisten Applikationen üblich) mehrere ViewModels haben. In jedem der ViewModels müssten wir das INotifyPropertyChanged implementieren und den Code immer und immer wieder schreiben – bäh!

PropertyChangedBase-Klasse

Deshalb kommen wir zu einer weiteren Verbesserung, wir vererben die erstellte Funktionalität einfach weiter und bauen uns sogar noch eine zentrale Methode zum Auslösen des „PropertyChanged“-Ereignisses. Erstelle also nun die folgende Klasse, in einem „Utils“ Unterordner Deines Projekts, von der Du dann anschließend in folgenden Projekten und ViewModels erben kannst. Beachte, dass Du Diese natürlich in den passenden Namespace packen solltest!

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;
}

Die „NotifyOfPropertyChange“-Methode bietet uns hier neben dem einfachen Auslösen des Ereignisses auch noch weitere Vorteile. Wir verwenden das „CallerMemberName“-Attribut für die Erfassung des „Property“-Namens. Wir müssen dann nicht zwangsweise den Namen der Eigenschaft angeben, er erkennt die aufrufende Property automatisch. Nur wenn wir bei einer Änderung des Vornamens, z. B. die Änderung der darauf basierenden „FullName Readonly Property“ kommunizieren wollen würden, müssen wir den Namen explizit angeben.

Ein ViewModel mit der Basis-Klasse

Deine folgenden ViewModels könntest Du nun also wie folgt erstellen. Passe hierbei Dein View ggf. noch an, indem Du zwei weitere Textblöcke mit passenden Bindungen hinzufügst. Ich habe testweise 1 weitere Eigenschaften, namens „LastName“ und eine auf beiden vorherigen basierende Eigenschaft namens „FullName“ hinzugefügt.

Imports <YOURPROJECTNAME>.Utils

Namespace ViewModels

    Public Class NewMainViewModel
        Inherits PropertyChangedBase

        Private _firstName As String

        Public Property FirstName As String
            Get
                Return _firstName
            End Get
            Set(value As String)
                If _firstName = value Then
                    Return
                End If
                _firstName = value
                NotifyOfPropertyChange()
                NotifyOfPropertyChange(NameOf(FullName))
            End Set
        End Property

        Private _lastName As String

        Public Property LastName As String
            Get
                Return _lastName
            End Get
            Set(value As String)
                If _lastName = value Then
                    Return
                End If
                _lastName = value
                NotifyOfPropertyChange()
                NotifyOfPropertyChange(NameOf(FullName))
            End Set
        End Property

        Public ReadOnly Property FullName As String
            Get
                Return $"{FirstName} {LastName}"
            End Get
        End Property

        Sub New()
            FirstName = "Robert"
            LastName = "Skibbe"
            ChangeAfterSeconds()
        End Sub

        Private Async Sub ChangeAfterSeconds()
            Await Task.Delay(2000)
            FirstName = "Hans"
            LastName = "Mustermann"
        End Sub

    End Class

End Namespace

using <YOURPROJECTNAME>.Utils;

namespace ViewModels
{
    public class NewMainViewModel : PropertyChangedBase
    {
        private string _firstName;

        public string FirstName
        {
            get
            {
                return _firstName;
            }
            set
            {
                if (_firstName == value)
                    return;
                _firstName = value;
                NotifyOfPropertyChange();
                NotifyOfPropertyChange(nameof(FullName));
            }
        }

        private string _lastName;

        public string LastName
        {
            get
            {
                return _lastName;
            }
            set
            {
                if (_lastName == value)
                    return;
                _lastName = value;
                NotifyOfPropertyChange();
                NotifyOfPropertyChange(nameof(FullName));
            }
        }

        public string FullName
        {
            get
            {
                return $"{FirstName} {LastName}";
            }
        }

        public NewMainViewModel()
        {
            FirstName = "Robert";
            LastName = "Skibbe";
            ChangeAfterSeconds();
        }

        private async void ChangeAfterSeconds()
        {
            await Task.Delay(2000);
            FirstName = "Hans";
            LastName = "Mustermann";
        }
    }
}

Weiterführende Links

• Was ist ConfigureAwait und warum sollte „False“ der Standard sein?
• Die ultimative VB.NET Background Worker Anleitung
• VB NET Dictionary – ein kompletter Guide

Der Beitrag Der ultimative INotifyPropertyChanged Guide in 2026 – für C# & VB.NET erschien zuerst auf Robert Skibbe.