Bindung nach Entity Model first aktualisiert Daten nicht!

  • WPF

Es gibt 118 Antworten in diesem Thema. Der letzte Beitrag () ist von Jeiss.

    Naja, ich musste auch noch _context.Database.CreateIfNotExists einfügen da ja bei uns die DB noch nicht erstellt wurde.
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    ErfinderDesRades schrieb:

    Mir scheint, das ChangeTracking bekommt nicht mit, wenn ich im DG einen UrgendOrder anlege.

    Bei mir schon lange. Man muss nur korrekt befüllen. Ausserdem hat er sein T4 total vermurkst. Eine ObservableCollection hat in einem Model nix zu suchen. Bei EF sollte man mit Icollections arbeiten.

    Grüße
    Sascha

    EDIT:
    Schade, jetzt kann ich meinen Post nur bearbeiten. @Jeiss bei deinem letzten Thema hat dir @ErfinderDesRades ja super gute Upload erstellt mit vielen tollen Beispielen...
    Die finde ich alle nicht in deinem Projekt. Da frage ich mich ob du überhaupt sauber proggen willst oder nicht.

    Also, ich habe dir nun ein sauberes ViewModel erstellt und dieses als DatenContext dem MainWindow zugeordnet. Das Mainwindow hat nun keinen CodeBehind mehr. Braucht auch niemand.
    Jetzt wird (sofern die Zeile gewechselt wird, das ist das Default verhalten vom DataGrid) der "Save" Button aktiv was signalisiert das der Context änderungen im ChangeTracker verzeichnet hat (siehe SaveCommand_CanExecute).
    Der Button ist nämlich brav wie es sich gehört auf einen Command gebunden, wodurch solch ein verhalten möglich wird.

    Add und Delete von Objekten (Delete geht auch mit Zeile mrkieren und DEL drücken) wird im passenden Event der CollectionView erledigt. Aber das siehst du ja im Code.
    Connectionstring in der config musst du anpassen.

    PS: Ist nur ein schneller Beispiel, code ist jetzt nicht perfekt und geht sicher an eineige stellen besser, aber ich will dir ja nicht den ganzen spass an der Sache nehmen. :)

    Grüße
    Sascha
    Dateien
    • EF.zip

      (465,23 kB, 33 mal heruntergeladen, zuletzt: )
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Nofear23m“ ()

    Hallo,
    freue mich jetzt schon drauf das verbesserte und ja jetzt auch speicherfähige Projekt zu testen.
    Aber bevor es losgeht glaube bin ich dir und den anderen hilfsbereiten Menschen die mich die letzten Wochen, mit viel Geduld, vor dem Verzweifeln bewahrt haben.

    Ja das mit dem sauberen programmieren, klar will ich das. Natürlich nicht so wie ihr es tut, aber ich kann mich ja nur verbessern.....
    Ich erkläre mal ganz kurz was das hier einmal werden soll.
    Jetzt bin ich noch am üben, weil ich mal probieren möchte bei welchen Aufgaben ich an meine Grenzen stossen werde. Hatte mir das aber ehrlich gesagt nicht so schlimm vorgestellt.
    Also hier mal was dieses Programm später mal können soll.
    1) Es sollen Daten aus einer Excel Tabelle in eine "List/Collection" geladen werden und entweder in einer ListBox oder in einem Datagrid angezeigt werden. (Mit dem Teil hab ich mich noch nicht so viel beschäftigt. Hab das früher mal hingekriegt, also hoffe ich das irgendwie auf die Reihe zu kriegen. Kommt aber bestimmt als nächstes dran.)
    2) Der ausgewählte Datensatz aus dieser "Excel-Liste" soll dann an das DatenModell übergeben werden. (ist an sich das was ich mit der heute geposteten Problematik erreichen wollte.)
    3) Dieser aktive "UrgentOrder-Datensatz" soll dann einer (von vielen) gefilterten ListBoxen zugewiesen werden.(Das was mein voriges Thema, das mit den vielen verschieden gefilterten ListBoxen.)
    4) Die Zuweisung der UrgentOrders in den verschiedenen Listboxen soll beim verlassen/schließen des Programm in eine Datenbank gespeichert werden um beim nächsten Start des Programm unverändert geladen zu werden.

    So das ist so grob gesehen was ich erreichen möchte.
    Da ich aber Angst hatte mich in einem "zu großen" Projekt zu "verlieren" hab ich es vorgezogen erst an kleineren (und deshalb auch leichtere) Projekte die einzelnen Funktionalitäten des Fertigen Projektes zu üben. Und später dann alles in einem einzigen Projekt wieder zu verknüpfen.
    Ist bestimmt eine sehr unkonventionelle Art und Weise an ein Projekt ran zu gehen. Aber ich war mir bewusst, dass ich mit meinen sehr begrenzten Programmierfähigkeiten in einem großen Projekt nicht weit kommen würde. Mit den kleineren Projekten kann ich mich dann besser in "die Materie einarbeiten", natürlich nicht ohne fremde Hilfe...

    So dann wisst ihr wenigstens wie ich mir das vorgestellt hatte.
    Und ich werde mir noch etwas vornehmen. Da ich ja jetzt endlich begriffen hab, dass hier ja immer jemand ist der mir auf meine Fragen antwortet.
    Werde ich in Zukunft zuerst nachfragen ob jemand mir einen Rat geben kann, wie ich die Sache angehen soll. Statt erst irgend etwas zusammen zu coden, und dann erst, wenn nichts mehr geht, um Hilfe zu bitten. Das ist euch gegenüber ja auch fairer! Und es führt nebenbei bestimmt/hoffentlich auch für mich schneller zu einem "globaleren" überblick über WPF.

    So genug gequatscht, jetzt lade ich mir mal das "überarbeitete" Projekt runter.

    EDIT:
    ​Hab schon gleich eine Frage. Da ich ja noch nicht ganz genau weiss (und auch nie wissen werde) was genau du alles ändern musstest. Ich soll den Pfad in der App.config ja anpassen. D.h. ja hoffentlich, dass ich die gleiche ("meine" .mdf) benutzen kann/darf?
    Danke,
    Jeiss

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Jeiss“ ()

    Jeiss schrieb:

    Also hier mal was dieses Programm später mal können soll.

    Ist ja nicht so viel. Für die paar Befehle zur DB ist EntityFramework wohl wie mit Kanonen auf Spatzen zu schiessen. Aber OK. Einfacher ist es auf jeden Fall, aber beim EF gibt es eben auch viel zu lernen wie du merkst.
    Da ist die Frage: Will ich es sowieso lernen für "später" oder brauche ich sowas wirklich nur für dieses Projekt, dann würde ich das mit dem EF lassen.

    Jeiss schrieb:

    Da ich aber Angst hatte mich in einem "zu großen" Projekt zu "verlieren" hab ich es vorgezogen erst an kleineren (und deshalb auch leichtere) Projekte die einzelnen Funktionalitäten des Fertigen Projektes zu üben.

    Wenn du erstmal ein Projekt im MVVM aufgebaut hast wirst du hier keine Probleme mehr haben. Beim MVVM ist jeder kleine Programmteil wie ein kleines Modul zu sehen.
    Man kann es also völlig abgekoppelt auch handhaben. So kannst du ganz leicht einfach mal was probieren und wieder verwerfen. Das ist sehr angenehm und eines der Dinge die ich an MVVM liebe.
    Für jeden VIEW (für jedes Fenster wenn man so will) gibt es das passene ViewModel (Der Teil mit dem Code).
    Ist man wo auf dem Holzweg verwirft man einfach das VM und das V. Fertig.

    Jeiss schrieb:

    Hab schon gleich eine Frage. Da ich ja noch nicht ganz genau weiss (und auch nie wissen werde) was genau du alles ändern musstest. Ich soll den Pfad in der App.config ja anpassen. D.h. ja hoffentlich, dass ich die gleiche ("meine" .mdf) benutzen kann/darf?

    Ja, du kannst aber auch deine DB löschen!! Ich habe es so programmiert das eine neue DB erstellt wird wenn keine vorhanden.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    ich hab auch bischen rumprobiert - zufügen + speichern geht.
    Beim Löschen habich einen Bug gefixt, aber dennoch kommts danach noch beim Speichern zu einer Constraint-Exception.

    Ah - ich habe einen UrgendOrder gelöscht, der auch eine Answer hatte - mit ohne Answer habich garnet getestet.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „ErfinderDesRades“ ()

    Hallo Sacha,
    ich kann wieder einmal nur staunen.... Super!
    ​Bin zwar schon ziemlich müde, aber trotzdem, solange das "Eisen noch warm ist".
    ​Ich hab mir schon mal kurz dein ViewModel und das geänderte MainWindow kurz angekuckt. Da sind die Änderungen ziemlich offensichtlich und die schau ich mir noch genauer an, morgen.

    ​Aber wollte wissen, ob du auch an der .edmx sowie an der .edmx.sql Änderungen vornehmen musstest? Damit das "Save" sowie die Verbindung zur DB ordentlich funktionieren?

    Danke,
    ​Jeiss
    Hallo

    Nein, da musste ich nix ändern. Habe nur die .tt geändert damit keine ObservableCollection(of Answare) erstellt wird. Weis nicht von wo du das hast. Die Standard Templates kann man eigendlich zu 99% so belassen wie sie sind.
    Aber DIR (wird ErfinderDesRadesjetzt nicht gefallen) empfehle ich sowieso CodeFirst.
    Erstens wird es empfohlen und geht mit EF Core auch und zweitens ist es viel logischer wenn man noch nicht viel mit Datenmodellen zu tun hatte.

    PS: Wenn man müde wir bringt das nichts. Glaub mir. Wenn ich was lernen will mach ich das nach dem aufstehen. Kaffee machen und VisualStudio starten, da geht bei mir am meissten.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Sacha,

    Nofear23m schrieb:

    Habe nur die .tt geändert damit keine ObservableCollection(of Answare) erstellt wird.

    ja, ok kann ich sehen.

    VB.NET-Quellcode

    1. Public Overridable Property Answers As ICollection(Of Answer)

    Hab ich von einem MSDN-Tutorial (so ein "How to....") Aber wohl nicht aus dem Kontext wie ich es verstanden hab...

    Und übrigens, hast recht. Gehe jetzt schlafen, und morgen bin ich wieder fit für eine neue WPF-Stunde.

    @ErfinderDesRades
    Jag mir bloss jetzt keine Angst ein!
    Herr Doktor, Ist es etwas Schlimmes? :)

    Aber auch das will ich heute nicht mehr wissen. Der Bug ist morgen auch bestimmt noch da... :P
    Ich will den Tag mit einem "Erfolg" abschließen.

    Danke,
    Jeiss

    ErfinderDesRades schrieb:

    Beim Löschen habich einen Bug gefixt, aber dennoch kommts danach noch beim Speichern zu einer Constraint-Exception.
    Ah - ich habe einen UrgendOrder gelöscht, der auch eine Answer hatte - mit ohne Answer habich garnet getestet.

    Jeiss schrieb:

    @ErfinderDesRades
    Jag mir bloss jetzt keine Angst ein!
    Herr Doktor, Ist es etwas Schlimmes?
    Ja und vielleicht aber auch nicht.
    Zunächstmal so nicht zu gebrauchen.
    Andererseits typischer Fall von Schnellschuss - hatter ja gesagt, also hofflich ists zu korrigieren.
    Ich kanns nicht so leicht fixen - ich hab mit dem Krempel kaum Erfahrung.
    Möglicherweise wird es sich aber auch als etwas erweisen, was mich dann an EF malwieder ankotzen täte - nämlich falls es garnet vorgesehen ist, übergeordnete Datensätze löschen zu können, unter Ausnutzung von Löschweitergabe.
    Keine Ahnung - bin gespannt.
    Guten morgen alle

    ErfinderDesRades schrieb:

    Andererseits typischer Fall von Schnellschuss - hatter ja gesagt, also hofflich ists zu korrigieren.

    Ja, war ein schnellschuss. Das entschuldigt aber nicht das ich löschen erst gar nicht getestet hatte. Der Bug den du meinst war vermutlich das e.NewItem(0) anstatt e.OldItem(0).
    Asche über mein Haupt, was man einbaut sollte man auch Testen. Mein Fehler. Ich entschuldige mich dafür.

    ErfinderDesRades schrieb:

    Möglicherweise wird es sich aber auch als etwas erweisen, was mich dann an EF malwieder ankotzen täte

    Naja, ich denke nicht das dich das ankotzen würde. Beim ModelFirst ist einfach CascadeDeleting per Default auf False. So kann man keine Datensätze löschen wo noch Beziehungen von anderen Untergeordneten Datensätzen vorhanden sind. Wie z.b. wenn es für ein UrgentOrder noch Answers gibt.
    Löscht man alle Answers kann man auch UrgentOrder löschen. Ich habe mich jetzt nicht gespielt wie man es einschaltet sondern einfach korrekt gelöscht. Im Model First kann man es ganz einfach über die FluentAPI für jede Relation einstellen.

    Anbei jetzt ein Beispiel wie es sich denke ich gehört. Löschen, Einfügen, editieren (auch editieren von Answeres) inkl. editieren des Datums mit einem DatePicker.
    Auch die Answers werden nun brav wie es sich gehört über ein eigenes Property im VM gebunden. (ShownAnswers)
    Der DBcontext bekommt schön alle änderungen mit. Ohne Hexerei. Um das ging es ja in diesem Thread.
    @ErfinderDesRades findest du das das "Repeat Yourself" ist?
    Und nochmal @ErfinderDesRades ich glaube sogar das du mit dem EF Core deine Freude hättest. Das meine ich auch ernst. Ich glaube das es dir gefallen würde, wenn man mal weis wie es funzt ist EntityFramework eine echt geniale Sache.

    Edit: @Jeiss um nochmals darauf zurück zu kommen. Du willst sicher nicht warten bis ich bei meiner Tutorialreihe beim Kapitel MVVM angekommen bin. Gerne kannst du einen Thread aufmachen, irgendwie mit dem Titel. "Richtiger MVVM Aufbau". Dann können wir dir ja mal eine korrekte Projektmappe aufbauen wie es sich gehört. da hast du dann nicht nur Ordnung sondern bist auch ganz sicher mit MVVM unterwegs da der richtige Projektaufbau auch nichts anderes mehr zulässt. Denn man kommt ja gerne in versuchung.

    Schöne Grüße
    Sascha
    Dateien
    • EF_neu.rar

      (402,39 kB, 22 mal heruntergeladen, zuletzt: )
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von „Nofear23m“ ()

    Hallo bin auch wieder da.
    Ich kann ja nicht mit euch mitreden welche WPF-Prinzipien aus welchem Grund besser sind. Aber....

    Nofear23m schrieb:

    Beim ModelFirst ist einfach CascadeDeleting per Default auf False.


    Für meine Zwecke, also mit den UrgentOrders, wäre es aber sehr praktisch wenn beim deleten des UrgentOrders (wenn der endlich fertiggestellt und ausgeliefert worden ist) dann auch sämtliche dazugehörigen Antworten, Ausreden, Terminversprechen u.s.w. mit gelöscht werden würden. Oder?
    Geht das in der jetzigen Konfiguration?

    Uebrigens, bin fast schon von den Vorteilen des MVVM überzeugt. So viele dinge sind erheblich einfacher. Das binden der DataGrids an die UrgentOrderView ist finde ich auch weniger verwirrend. Und SaveCommand_CanExecute ist doch auch etwas tolles....
    Ich muss mich jetzt nur noch damit vertraut machen.
    Und damit ich es auch verstehe. Wieso ist es so wichtig den context zu disposen? Wann soll das passieren?

    EDIT:
    ​Wie öffne ich eine RAR-Datei. ZIP will nichts davon wissen...oder?

    Danke,
    Jeiss

    Jeiss schrieb:

    Uebrigens, bin fast schon von den Vorteilen des MVVM überzeugt. So viele dinge sind erheblich einfacher. Das binden der DataGrids an die UrgentOrderView ist finde ich auch weniger verwirrend. Und SaveCommand_CanExecute ist doch auch etwas tolles....

    Ja, Binding und Commands sind in der WPF schon was tolles und wenn man es mal versteht und merkt wie einfach man damit Arbeiten kann will man das System nicht mehr missen.

    Jeiss schrieb:

    Wieso ist es so wichtig den context zu disposen?

    DIe DBContext-Klasse implementiert IDisposable. Man sollte also immer mit einem Using-block arbeiten.

    VB.NET-Quellcode

    1. Using myContext as new UrgentOrderContext
    2. ...
    3. ...
    4. End using

    Da es aber so ist das du in deinem Fall wärend der ViewModel-Lebenszeit den Context wieder benötigst muss man das Objekt es an anderer stelle wieder freigeben um es aus dem Speicher zu werfen damit der GarbageCollector aufräumen kann. Das ist wichtig. Würdest du in deinem Beispiel im Contructor deines ViewModel einen Context mit Using verwenden und beim Speichern das ganz nochmals würder der Context NIEMALS eine änderung mitbekommen. Denn er war ja nicht dabei! Wenn der Context während der änderung nicht "anwesend" ist kann er auch nicht mitbekommen das sich etwas geändert hat. Wenn du dazwischen also das Objekt zerstörst und wieder ein neues Context-Objekt erstellst in dem Moment wenn du es brauchst weis er nichts davon. In diesem Fall müsste man dann mit Attach und EntityState dem Context sagen was sich wie geändert hätte, auch das ist möglich aber umständlich. Aber ich hole zu weit aus. Wie gesagt, mit dem EF kann man ganze Bücher füllen.

    Jeiss schrieb:

    Wann soll das passieren?

    Sobald du den Context nicht mehr benötigst. In dem Beispiel habe ich das im Disposing erledigt. Die Basisklasse ViewModelBase (von mir) implementiert die IDisposable Schnittstelle und enthält ein Overridabe Dispose.
    Diese Methode kann in jedem ViewModel (solange es von ViewModelBase erbt) überschrieben werden. In dem Beispiel passiert das nur nie da es das einzige ViewModel für das PRogramm ist.
    Aber wenn du in einem Programm z.b. einen Dialog aufmachst oder Ähnliches, willst du ja das ViewModel auch nach schliessen des Dialogs wieder im Speicher freigeben, und das machst du mit Dispose.
    Also z.b. MeineVMinstanz.Dispose()
    Und schon wird dafür gesorgt das der DBContext auch Disposed wird. Sauber und einfach beim proggen.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Wie immer, schön verständlich erklärt. Danke.
    ​Hatte immer gedacht, oder vielmehr gehofft der Gabagecollector würde seine Arbeit immer "automatisch" erledigen....

    ​Du noch ne Frage. Wie krieg ich die RAR-Datei auf Windows 10 auf. Muss ne Software runterladen... oder?
    Sorry hatte vergessen umzustellen. Ich zippe mit WinRar.
    Anbei die ZIP.

    Ja, der GC macht schon seine Arbeit. Aber nur dann wenn es Ihm erlaubt wurde. Bei Objekten welche IDisposable wird es Ihm salop gesagt verboten. Erst wenn du mit Dispose sagst das es jetzt in Ordnung ist das Objekt zu verwerfen kümmert er sich drum.

    Grüße
    Sascha
    Dateien
    • EF_neu.zip

      (474,41 kB, 22 mal heruntergeladen, zuletzt: )
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.
    Oh das ist aber wieder mal ausgesprochen nett von dir.
    ​Ehrlich gesagt zögere ich mit diesem Rechner (läuft gerade gut) irgendwelche freeware oder so runter zu laden.
    ​ Nachdem ich mir die "entbugte" Version ein wenig angekuckt habe, wird es für mich ernst werden.

    ​Dann will ich mich an den Teil des Projektes ran machen wo es darum geht die Orders (unter denen dann auch urgent orders sind) aus der Excel Tabelle, welche alle orders enthält, in ein VM zu laden. Du weißt ja schon, damit ich die dringendsten unter ihnen auf die verschiedene Workcenter "verteilen" kann damit sie "prioritär" abgearbeitet werden.
    ​Ich kann da auf so ein Code-fragment zugreifen das ich mir mal zusammengebastelt habe. Wenn ich mich nicht irre lädt es die Excel Daten in eine DataTable. Ja und ich weiss jetzt schon, dass das wieder ein furchtbares "Code-Gemetzel" werden wird. X/
    ​Und wenn du bei Google so was wie "WPF import data from Excel" eingibst, dann findest du alles, bloss nicht was ich für diese Aufgabe bräuchte. (oder in C#)
    ​Hast du, oder sonst jemand, vielleicht einen Tipp, LInk oder sonst eine Starthilfe für mich?
    ​Werde aber bestimmt bald für diese Aufgabe eine neue Frage posten.

    Danke,
    Jeiss
    Hallo

    ErfinderDesRades schrieb:

    und CascadeDeleting anstellen geht nicht?

    Habe ich gerade mal probiert. Du weist ja, ich mag klickiBunti Designer nicht. Geht aber ganz leicht.
    Erst die Beziehung anklicken und dann im Eigenschaftenfenster umstellen. Fertich.


    Jeiss schrieb:

    oder in C#

    Dann nimm einen Converter

    Jeiss schrieb:

    Werde aber bestimmt bald für diese Aufgabe eine neue Frage posten.

    Naja, kostet ja nix. Wenn du wo hängst dann frag hald einfach. Excel auslesen gibt es ja mehr als genug Beispiele im Netz. Die einen mehr die anderen weniger gut.
    Pauschal kann ich dir da jetzt nicht Helfen, wir kennen nicht das Excel File und nicht was eingelesen werden soll. Aber das wäre hier in diesem Thread auch fehl am Platz.

    PS: Sei so gut, wenn dir ein Beitrag gefällt kannste gerne mal auf "Hilfreich" klicken. 8o
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.

    Nofear23m schrieb:

    Sei so gut, wenn dir ein Beitrag gefällt kannste gerne mal auf "Hilfreich" klicken.

    ​Ja stimmt, du hast natürlich recht. Aber ich bin oft so mit "dem Auswerten" der Antworten beschäftigt. Ich will das ja auch verstehen was drin steht...
    ​Und, dann ist es bei mir ja auch so, dass es eher ein Button geben müsste wenn eine Antwort mal nicht Hilfreich wäre :)

    ​Danke für den Konverter, den hatte ich noch nicht.

    Du hast dem DataGrid auch ein kleines Lifting verpasst. Auch sehr sauber.

    Danke,
    Jeiss

    Jeiss schrieb:

    Du hast dem DataGrid auch ein kleines Lifting verpasst


    Ja, und das setzen des UpdateSourceTrigger auf OnPropertyChanged bewirkt das man nun nicht die Zeile wechseln muss damit die änderungen erkannt werden. Nun wird nach einer Änderung sofort der "Save" Button aktiv. ;)
    Auch kann nun das Datum über einen DatePicker editiert werden. Ist ja unschön ein Datum einzugeben. (hier kommt auch ganz oben beim Window das Language Property zu tragen, was auf "de.DE" festgelegt wurde damit Datumsangaben im korrekten DE Format angezeigt werden.

    PS: Bevor du mit Excel und was weis ich was anfängst würde ich abklären ob du nun mit MVVM anfangen willst oder nicht. Hier gibt es nämlich einiges zu lernen und da würde ich mich jetzt nicht mit etwas beschäftigen was du dann vieleicht sowieso komplett umbauen müsstest. Nur ein Tipp.

    Grüße
    Sascha
    If _work = worktype.hard Then Me.Drink(Coffee)
    Seht euch auch meine Tutorialreihe <WPF Lernen/> an oder abonniert meinen YouTube Kanal.