Suchergebnisse

ausgelagert aus WinForms Projektentwicklung bzgl. der Rolle des Formulars ~VaporiZed Zitat von Amro: „Erstell das ganze erst in WPF und MVVM.“Leichter gesagt als getan, da ich von WPF null Plan hab. Also mein XAML-Code sieht zum aus. Aber es klappt - zumindest bis auf das Schließen. Überrascht hat mich nur, dass im ViewModel bei WinForms OnPropertyChanged für eine Property reicht, um alle zu aktualisieren, in der WPF muss ich es für jede einzelne Property machen.

Achso, Du meinst, dass eben dann ein passender DialogService für das View bereit gestellt werden muss und das ViewModel unabhängig davon bleibt und einfach nur indirekt dem WinForms-DialogService bescheid gibt: "Mach mal." und die eigentliche Arbeit auf ihn abwälzt. Ja, sowas hatte ich auch kurz im Unsinn, ob das der Weg ist, da mir mal vor ein paar Jahren Nofear23m ein kleines Projekt für mich zusammengebastelt hatte. Aber mir fehlte bis heute die Muße, sein Ergebnis genau zu analysieren, weil …

Jou, genau, das war eben noch der Denkfehler. Also: Wegabstrahieren, was nicht generisch ist. Vielen Dank.

Zitat von dive26: „Aber ist es nicht bei jedem VB6/VB.NET Anfänger so, dass man mit Winforms beginnt und dann den kompletten Code (meist aus Unwissenheit) direkt in der Form verwaltet?“Richtig. Und genau deshalb, hatte ich damals den Thread aufgemacht, um bessere Wege zu zeigen. Weil viele sich nämlich in Spaghetticode verheddern, nicht mehr rauskommen und dann entweder frustriert aufgeben oder von anderen den Kopf gewaschen bekommen. Du bist jetzt seit 20 Jahren dabei und hast fantastisch gutta…

Das mit Command und CommandParameter klappt schon. Man muss nur mindestens .NET 7 einstellen. Bei .NET 8 klappt es ohne weitere Angaben, bei .NET 7 muss man ein wenig nachhelfen, siehe Diskussionsthread: MVVM mit WinForms - kleiner Einstieg für Anfänger

Ich kann dazu nicht viel sagen, da ich mit der detaillierten MVVM-Geschichte, v.a. in der WPF noch überfordert bin. Ich hab mir das aus den Beispielen von @Nofear23m und @Amro so zusammengereimt, dass es Helferklassen sind, die je nur einen Zweck erfüllen. In dem Fall ist der DialogService wohl dazu da, um in der WPF ein leeres DialogWindow mit einem UserControl mit dem eigentlichen Inhalt erzeugen und dies anzuzeigen und zu schließen. In WinForms verwendet @Amro den DialogService, um eben auf A…

Contract - Vertrag? Nuja, das Teil macht ja irgendwas. Sollte sich der Name nicht daran orientieren? Ein Vertrag wär für mich fast schon ein Interface - oder vice versa. Vielleicht sollte man es auch einfach spezifisch so benennen wie die Aufgabe, die es erfüllt. Hier vielleicht ViewCreator. Obwohl es wohl zukünftig wohl mehr macht als nur erschaffen . Manager sollte man wohl immer bei der Benennung meiden, weil jede Klasse irgendwas managt. @ErfinderDesRades: Bei Dir würde es wohl in die Katego…

Achso. Ich dachte, die Klasse heißt irgendwas mit Contract. Dass das Interface so genannt wird, lass ich mir einreden. Auch wenn ich das moppelt gedoppelt finde. Ein Interface ist für mich ja eine Art Vertrag, da brauch ich das nicht noch im Namen. Ich versuch es ja eher so zu halten, dass der Interfacename aussagt, was der Vertrag über den Implementierer aussagt - falls möglich. Klappt aber auch nicht immer. So z.B. ICloseable, aber eben auch IManagedShutdown. Aber gut, dann zur Kenntnis genomm…