Vererbung der MainForm und wiederholter Aufruf des basis Constructors

Ich weiß nicht, ob ich einen grundsätzlichen Fehler begehe, wenn ich von meiner MainForm Klasse andere Klassen ableite und diese ja immer auch wieder den basis Constructor aufrufen...
Ich hätte da gern ein paar hinweisende Hilfestellungen, um nicht grundsätzlich weiter falsch zu arbeiten.

Zum kurzen Verständnis:
Ich habe C# sehr schnell durch notwendiges Refactoring und Reverse Engineering einer vorhanden Software in meiner Firma lernen müssen, da der bisherige Programmierer die Firma kurzfristig verlassen hatte. Ich lerne also seit einem Jahr mit einigen Pausen hauptsächlich anhand eines Programms, das auch von einem nicht wirklich handwerklich sicheren Typen geschrieben worden war.
Die Funktionalität habe ich fast komplett im Griff, die GUI ist auf Vordermann gebracht ABER ich stecke jetzt an zwei Punkten fest, die schon im grundsätzlichen liegen dürften und eventuell durch mein nicht vorhandenes Grundlagenwissen weiter falsch gemacht wurden.

Ich habe (Windows Forms App) eine MainForm, über die alles abläuft. Ich arbeite mit zwei kurzen parallelen Threads, die eine andere Software aufrufen und dort ein Projekt laden, der grundsätzliche Ablauf erfolgt aber in meiner Software.
Die meisten Methoden sind als Funktionen in eigene .cs Dateien "ausgelagert" und als partial class integriert. Das funktioniert alles sehr gut.
Auch eine extra Setup Form, die über eine Object, was mit dem Aufruf mitgeliefert wird, mit den GUI Labels kommuniziert.

Jetzt die erste Frage:
Ist es grundsätzlich falsch, Klassen von der MainForm Basisklasse abzuleiten, nur um Zugriff auf die GUI zu bekommen?
Ich habe auch eine Extra-Klasse "SaveData" gebaut, die im Ablauf instanziiert wird und dann deren Member beschrieben und die Methoden aufgerufen werden. Das funktioniert auch bisher sehr gut.
Jetzt ist mir aber aufgefallen, dass jedesmal an der Stelle im Programm, wo ich die SaveData Klasse instanziiere, der Constructer der MainForm aufgerufen wird...warum? klar, weil ich die Klasse SaveData : MainForm ableite.
Weil ich ja Zugriff auf die ganzen GUI Objekte haben möchte.

Bisher alles kein Problem, aber ich habe nun im Constructor der MainForm einiges hinzugefügt, was am Anfang des Programms funktioniert, aber nicht mittendrin, daher hatte ich nun immer Exceptions beim erreichen des SaveData Aufrufs.

Ist es richtig, so etwas immer mit Übergabe eines MainForm Objektes zu bewerkstelligen und nicht von der MainForm abzuleiten?

also z.B.
classNew(MainForm Caller)
{
Caller.setText(""); //Zugriff auf GUI
}
(alle dies Aufrufe habe ich natürlich schon Threadsicher gemacht....)

Wenn ich das richtig verstanden habe, wird der Constructor der basis grundsätzlich immer mit aufgerufen, vor allen Dingen dann, wenn er parameterlos ist?

Ich hatte auch eine Lösung gefunden, dass man erst eine "absolute" Oberklasse erschaffen sollte und davon dann die MainForm und alle anderen Klassen ableiten kann und damit Zugriff auf alle Member, sprich auch die GUI bekommt. Ist das richtig und sinnvoll?

Wenn ich das richtig verstanden habe, wird der Constructor der basis grundsätzlich immer mit aufgerufen, vor allen Dingen dann, wenn er parameterlos ist?

Richtig. Das sind aber sehr grundlegende Dinge, die man auch sehr schnell in der Doku nachschlagen kann. Daher habe ich den Beitrag ins Grundlagenforum verschoben.
[Tipp] Schau in die Doku! - Möglichkeiten der Informationsgewinnung

Ansonsten klingt dein Beitrag so, als willst du Windows Forms dazu verwenden, deine Anwendungs-Logik zu implementieren. Die Forms stellen aber nur die Benutzeroberfläche da, also die Ausgabe und die Eingabe von Daten. Der Rest hat dort nichts zu suchen. Dann werden sich auch alle genannten Probleme von allein lösen.

Siehe dazu u.a.: [Artikel] Drei-Schichten-Architektur

Danke MrSparkle.

Klar, Dokus etc....alles schon zur Genüge gemacht, in deutsch und in englisch, auch Bücher. Aber manche Dinge scheinen "so selbstverständlich", dass sie kaum erwähnt werden, bzw. das Wissen darum stillschweigend vorausgesetzt wird, mit Sicherheit niemals absichtlich.
Ich habe mit dieser (auch schlecht) dokumentieren Software sehr viel zu kämpfen, da diese in der Produktion in unser Firma täglich eingesetzt wird und einiges davon abhängt.
Ich wollte nach ca. einem halben Jahr ein komplettes Rewrite, also 2.0 machen, das schaffe ich aber nicht parallel, leider.
Von daher muss ich mit vielen Krücken noch leben und komme nur stückchenweise weiter. Jetzt, nachdem ich die meisten "Unschönheiten" beseitigt habe, auch die GUI moderner Arbeitsweise angepasst habe, muss ich an die "arbeitsverhindernden" Fehler und diese kommen dann von so tief, dass ich erstmal davor noch drei andere Schritte verstehen muss.

Aber manchmal sieht man den Wald vor lauter Bäumen nicht und wenn sich erst mal ein grundsätzlicher Fehler eingeschlichen hat, gehts munter weiter damit, das will ich in einigen Teilen jetzt verhindern.
Ich selbst komme mit meinem Wissen aus dem Anfang der 80er mit Z80 Maschinensprache und später dann Basic und noch später BlitzBasic, ein OO Basic.
Aber ich habe mein Grundverständnis halt in Spaghetticode und Ablaufsteuerung von oben nach unten im Code. Daher bin ich vor Jahren erstmal mit dem coden von Apple Software gescheitert, das Verarbeiten von Nachrichten und keinen strukturierten Ablauf hat mich komplett zerlegt...war ja damals auch nicht mein Job. Heute muss ich das und es reizt mich um so mehr....

Also das Drei Schichten Modell
habe mir die Zeit genommen, alle Posts dazu zu lesen....
Ich denke, dass ich dass definitiv verfolgen muss, aber natürlich nicht ohne ein fast komplettes Rewrite hinbekommen werde.

Entscheidend ist, dass ich wohl tatsächlich als erstes daran arbeiten muss, die ganze Logik aus der MainForm Klasse zu bekommen.
Der Constructor der MainForm ruft tatsächlich sehr viele Methoden auf, die nichts mit der eigentlich Form zu tun haben. Unter anderem auch das Instanziieren des API Objektes und das fällt mir jetzt auf die Füsse.

Wenn ich mir das jetzt genau überlege, war das ein Blindflug bisher, und es ist nichts weiter gravierendes aufgetreten. Ich habe den Constructor der MainForm etliche Male "aus Versehen" immer wieder aufgerufen.....das dürfte sicher absoluter Unsinn gewesen sein oder? Nur um an die GUI zu kommen...
Aber so war das ursprünglich auch programmiert und ich habe das so weiter gemacht.

Wenn ich Deine Grafik richtig verstehe, dann erfolgt der Zugriff immer von oben nach unten, also darf meine Logic niemals auf die GUI zugreifen , sondern die GUI holt sich die Daten in z.B. einem Zeitintervall ab oder wenn sie benachrichtigt wird?
Das setzt natürlich eine komplette Änderung meines Codes voraus, da ich permanent aus meinem Ablauf Labels mit Text füttere und Buttons akt- und deaktiviere usw.
Der Ablauf wäre doch die Logic-Schicht oder?

Wenn ich einen Button (Präsentationsschicht) drücke, dann rufe ich doch eine Methode (Logikschicht) auf. Das Ergebnis kommt dann wie zur Präsentationsschicht?
über Return Parameter?
Die Methode zum Füllen einer ComboBox gehört die in die erste oder zweite Schicht?

Fragen über Fragen....

Ich denke wir verstehen Deinen Frust - aber wie können wir helfen?
Das Forum kann sehr gut bei konkreten Probleme helfen, Dich auf konzeptionelle Dinge hinweisen - aber Grundlagen und die Umsetzung, das bleibt halt bei Dir.

Also das Drei Schichten Modell
habe mir die Zeit genommen, alle Posts dazu zu lesen....

Lesen reicht nicht; musst ja auch verstehen 😃

Ich denke, dass ich dass definitiv verfolgen muss, aber natürlich nicht ohne ein fast komplettes Rewrite hinbekommen werde.

Sicherlich wirds irgendwie mit Spaghetti-Code funktionieren - es gibt immer einen Weg; aber da können wir de facto nicht helfen.
Wir können Dir aber sagen, wie es prinzipiell richtig geht.

Wenn ich Deine Grafik richtig verstehe, dann erfolgt der Zugriff immer von oben nach unten, also darf meine Logic niemals auf die GUI zugreifen , sondern die GUI holt sich die Daten in z.B. einem Zeitintervall ab oder wenn sie benachrichtigt wird?

Die Grundidee von diesem Architekturvorgehen ist, dass Deine Logik nichts von der UI kennt, sodass die Logik in verschiedenen Anwendungstypen (Desktop, Web, Mobile..) und den dazu gehörenden Technologien funktioniert.
Hat die Logik Kenntnis der UI, dann ist de facto die Modularität tot.

Der Ablauf wäre doch die Logic-Schicht oder?

Sofern Ablauf im Sinne von "Es passiert etwas", dann ja.
Dann muss die Logik mit Hilfe von Events informieren, dass etwas passiert ist - und die UI nimmt die Events entgegen und füllt damit zB Labels.

Das Ergebnis kommt dann wie zur Präsentationsschicht?

Hast den Beitrag also eher überflogen statt gelesen 😉
Synchrone Ergebnisse kommen über Rückgaben; Ereignisse über Events.

Hallo,

das Ableiten ist auf jeden Fall der komplett falsche Ansatz, denn wie du schon erkannt hast, wird dabei immer ein neues MainForm-Objekt erstellt (das nichts mit dem sichtbaren MainForm zu tun hat - du kannst dann zwar auf dessen Methoden zugreifen, aber da es eine anderes Objekt [Instanz] ist, nicht auf dessen [aktuelle] Daten). Der richtige Weg wird in [FAQ] Kommunikation von 2 Forms bzw. etwas genauer in meinem eigenen Artikel Kommunikation von 2 Forms erklärt (Stichwort: Ereignis - wie auch schon von Abt genannt).

Hallo Th69,

Danke, genau das habe ich gesucht. Ich hatte heute früh schon den Artikel mit der Kommunikation von 2 Forms am Wickel, sehr aufschlussreich, gehe ich heute Abend mit Freude komplett durch.
Ich habe gerade eben genau das ausprobiert, es war totaler Quatsch was ich da gemacht habe. In der Tat hatte ich zwar einen funktionierenden Zugriff auf die "globalen" Felder der MainForm, aber der Aufruf der Methoden ging ins Leere! Das hat deswegen niemand gestört, weil ich damit nur Debug Kommentare in eine Textbox geschrieben habe, die zusätzlich in eine Log Datei geschrieben wurden. Das diese ganzen Kommentare aus den Klassen, wo das definitiv ins Leere lief, nicht da waren, ist mir nie aufgefallen...da sieht man wie wichtig das wohl war....

Also ich werde anfangen das komplett zu überdenken.
Jetzt ist es so, dass ich praktisch den gesamten Code als partial in der Main Form habe, bis auf wenige Ausnahmen.

Eine Frage: wenn ich das jetzt angehe und sowieso das Ganze aufdröseln muss, sollte ich das gleich in WPF machen, also Portieren ? Bis jetzt ist es WindowsForms....

Wenn die Logik unabhängig funktioniert, dann wäre das doch genau der Punkt, wo ich das auch gleich miterledigen kann oder?

Gestern schriebst du, daß dein Wissen nicht ausreicht, um in der Doku nachzuschlagen, ob ein Konstruktur der Basisklasse automatisch aufgerufen wird. Heute willst du eine komplette Software neu schreiben, und nebenbei gleich noch eine neue Technologie erlernen.

Meine Empfehlung wäre: lieber erstmal etwas kleinere Brötchen zu backen.

Da wir aber weder die Struktur der Software noch deiner Firma kennen, können wir auch keine konkreten Tips geben. Außer evtl. erstmal kleinere Projekte starten, Funktionalität dorthin auslagern, Technologien evaluieren (es gibt nicht nur WinForms und WPF!), Vorgehensweise aus der Software-Entwicklung anwenden, Projekt-Management einführen, automatische Tests ausrollen etc., um von dem "Grundverständnis in Spaghetticode" und Einzelkämpfermodus wegzukommen.

ich habe bestimmt nicht geschrieben, das mein Wissen nicht ausreicht um in einer Doku nachzuschlagen..im Gegenteil, ich habe geschrieben, dass ich etliche Bücher über C# in deutsch und englisch einigermaßen durchgearbeitet habe, zig Online Dokumentationen , auch die vonMicrosoft, permanent offen habe um weiter zu kommen.
Was ich wollte, sind Denkansätze, da man bei soviel Input mal schnell den Überblick verliert und komplett in die falsche Richtung läuft.
Das Drei-Schichten-Modell ist genau der Ansatz, den ich gesucht habe, da werde ich mich hinterklemmen.
Das löst mit einem Schlag eine Menge Probleme die ich habe und noch kommen sehe, auch in Bezug auf Multithreading.

Und wie man sieht, habe ich einige Fehler übernommen und schön weiter durchgezogen...

Ich würde aber gern das Drei Schichten Modell noch weiter erörtern, ich kann aber auch weiter googeln....

zweiter Teil der Antwort:

vom Einzelkämpfermodus komme ich hier in der Firma nicht weg, zumindest nicht was diesen Bereich für diese Software betrifft, die anderen Programmierer sind für die Produkte hier zuständig und schreiben in Linux oder QT C++...die wollen von mir und C# nichts wissen, warum auch immer...

Diese Software, die ich pflege, ist essentiell in der Qualitätssicherung unserer Firma. Grob umschrieben macht sie folgendes:

Die Software ist einigermaßen komplex, da sie Geräte mit ihren Eigenschaften verwaltet, serielle Verbindungen aufbaut um die Geräte parallel zur Messung zu steuern, eventuelle Firmware Upgrades durchführt (tatsächlich von einem Programmierer hier ein Kommandozeilentool dafür bekommen), die Messungen anhand einer Abfolge aus der Messgerätesoftware einzeln durchführt, eventuell bei überschreiten von Limits diese wiederholt, die Ergebnisse auswertet, gerätespezifische Deckblätter erstellt, von der gesamten Messung ein PDF aus einer (von der Messsoftware erzeugten) HTML Datei erstellt und ausdruckt und die Ergebnisse archiviert.

Das Ganze habe ich ohne Dokumentation des ursprünglichen Autors, reverse engeneerd, die Fluss Diagramme erstellt um überhaupt daran arbeiten zu können und halte die Software seit einem Jahr in der Produktion am laufen und entwickle sie parallel weiter. Mit entsprechenden Revisionen, beta Status etc. und RollOut für die 3 Messtürme, wo diese Software dann die Audio Pression Messgeräte steuert.

Soviel dazu.

Meine Hoffnung war, hier auch Denkansätze zu erörtern, damit ich, wenn ich jetzt den Schritt zur Version 3.0 mache, auch den richtigen Weg einschlage.
Ich habe auch schon mit WPF programmiert, das ist mir also nicht fremd und in der Tat scheint es dem Ansatz des Drei Schichten Modells auch deutlich näher zu kommen, als Forms. Zumindest sieht für mich das Event Handling und das Databinding deutlich danach aus. Oder sehe ich das falsch?

Zuerst solltest du ersteinmal die ganze Logik (sowie Datenschicht) kapseln (denn so wie du es beschrieben hast, ist das ganze komplett ohne UI auslagerbar), am besten sogar in einer eigenen Bibliothek (Class Library). Wenn du das hast, und den bisherigen WinForms-Code soweit entschlackt hast, daß dort nur noch UI spezifischer Code enthalten ist, welcher dann die entsprechenden Methoden der (Business) Class Library aufruft, erst dann solltest du dir überlegen nach WPF umzusteigen (denn dort solltest du dann auch noch gleich MVVM benutzen: [Artikel] MVVM und DataBinding).

Das 3-Schichten-Modell ist ersteinmal komplett unabhängig von der verwendeten UI-Technologie (auch in WinForms oder sogar Konsolenanwendungen kann man Ereignisse und DataBinding verwenden, auch wenn WPF dies mehr voraussetzt).

Diese Software, die ich pflege, ist essentiell in der Qualitätssicherung unserer Firma. Grob umschrieben macht sie folgendes:

Die Software ist einigermaßen komplex, da sie Geräte mit ihren Eigenschaften verwaltet, serielle Verbindungen aufbaut um die Geräte parallel zur Messung zu steuern, eventuelle Firmware Upgrades durchführt (tatsächlich von einem Programmierer hier ein Kommandozeilentool dafür bekommen), die Messungen anhand einer Abfolge aus der Messgerätesoftware einzeln durchführt, eventuell bei überschreiten von Limits diese wiederholt, die Ergebnisse auswertet, gerätespezifische Deckblätter erstellt, von der gesamten Messung ein PDF aus einer (von der Messsoftware erzeugten) HTML Datei erstellt und ausdruckt und die Ergebnisse archiviert.

[...]

Meine Hoffnung war, hier auch Denkansätze zu erörtern, damit ich, wenn ich jetzt den Schritt zur Version 3.0 mache, auch den richtigen Weg einschlage.
Ich habe auch schon mit WPF programmiert, das ist mir also nicht fremd und in der Tat scheint es dem Ansatz des Drei Schichten Modells auch deutlich näher zu kommen, als Forms. Zumindest sieht für mich das Event Handling und das Databinding deutlich danach aus. Oder sehe ich das falsch?

Deine Software scheint aus der Aufzählung ja nur eine recht einfache GUI zu benötigen, von daher sehe ich nicht wirklich den Sinn den Wechsel von Winforms zu WPF zu fokusieren.

Wie schon von den anderen geschrieben, erstelle die verschiedenen Schichten und schiebe deine Logik aus der GUI. Dann sollte dort nicht mehr viel übrig bleiben. Dann kann man zum Schluss immer noch wechseln.

Genau so, das Ziel hatte ich schon verschwommen vor den Augen, jetzt habe ich auch eine Weg.
Da ich den Ablauf der gesamten Messprozedur sehr genau kenne und jeder Abschnitt schon für sich aufgedröselt ist, würde ich vielleicht folgendermaßen an die Sache rangehen:

Gleich ein WPF Projekt anfangen

Da keinerlei Crossplattform Absichten bestehen, die API gibts nur für Windows, kann ich mich eigentlich mit der Präsentationsschicht früh festlegen und auf WPF einfach die alte bewährte GUI "nachbauen", mit sicherlich ein paar neuen Designs

Dann würde ich Schritt für Schritt die einzelnen Ablaufmodule in die Business-Class eigenständig portieren und dabei Step by Step die Funktionalität überprüfen.
Das kann ich ja ganz gemütlich machen, weil ich ja durch die neue Struktur sicher sein kann, dass ich notwendige Veränderungen, die ich zwischenzeitlich gezwungenermaßen an der alten Version vornehmen muss, jederzeit problemlos nach-portieren kann. Ich muss ja nicht mehr so auf die direkte GUI Einbindung achten!

Letztendlich würde ich das Programm komplett neu aufbauen, natürlich mit viel Copy und Paste wo es geht, aber dann dürfte eine Menge Müll einfach verschwinden, wenn ich unnützes Zeug dadurch aussortieren kann.

By the Way, ich muss mich natürlich auch um die Lebenserhaltung des MarshalbyReference Objektes kümmern...

Ich denke den Wechsel frühzeitig zu machen, ist wichtig, um gleich auch in der "Sprache" von WPF zu sein. Und da ich ja eh ziemlich bei Null anfange, wenn ich die gesamte Struktur so dermaßen verändere, dann kann ich das auch gleich in dem Projekt machen, wo es zum Schluss auch bleiben soll. So denke ich zumindest

Ich halte dagegen, dass jede Änderung insbesondere an den Fundamenten Fehlerpotential birgt, und ich dies der Reihe nach erledigen würde, mit der GUI zum Schluss.

Aber es ist deine Entscheidung.

Ich denke den Wechsel frühzeitig zu machen, ist wichtig, um gleich auch in der "Sprache" von WPF zu sein.

Sowas gibt es nicht.

Ist die Logikschicht sauber spielt es keine Rolle ob diese von ASP.NET, WinForms oder WPF konsumiert wird.
Nimm MrSparkles Rat an und mach lieber zuerst kleine Schritte..

Ja, ich geb euch beiden Recht, wahrscheinlich ist es besser so.

Was ich damit bezwecken will, ist, dass ich gleich C#8.0 nutzen kann, das geht aber nur mit Core und nicht Framework. Und Core geht nur in einem WPF Projekt , der Designer ist wohl noch nicht fertig um Forms zu benutzen.

Habe ich das soweit richtig verstanden?

Aber ich halte mich gerne erst mal an eure Vorschläge, ich sitze eh schon am "alten" Code und entschlacke den gehörig und versuche schon Events einzuführen, um von der direkten GUI Element Ansprache wegzukommen.

Wenn ich das richtig verstanden habe:

Die Kommunikation der Business Schicht mit der GUI erfolgt NUR über Events, ich muss also in meiner neuen Logik Schicht also für alles, was ich mal angezeigt haben will, über ein General-Text-Event gehen und dass dann abfeuern...mit eigenen Parametern natürlich, nämlich den Text usw.

in meiner Präsentation-Schicht schreibe ich dann wenn das Event erkannt wird, den übergebenen Text in die TextBox.
Genial, das wollte ich schon immer, habe nur nie durchgeholt das Prinzip...

So ist es wurscht, ob ich die TextBox X, Y oder Z benenne, das interessiert meine Business-Schicht ja nicht...

Was ich damit bezwecken will, ist, dass ich gleich C#8.0 nutzen kann, das geht aber nur mit Core und nicht Framework.

Uff, da vermischt Du jetzt viel - und das hier wird zu einem Endlosthread.

C# 8 kann problemlos in .NET Standard Projekten verwendet werden.
.NET Standard Projekte können von .NET Framework referenziert werden.

Bibliotheken - und meistens lagert man eben Daten- und Logikschickt in solche aus - können übergreifend C# 8 verwendet werden.

der Designer ist wohl noch nicht fertig um Forms zu benutzen.

Der Designer ist ohnehin nur für Einsteiger. Kaum ein Fortgeschrittener nimmt den Designer (Erfahrungswerte).
Der Designer für .NET Core 3 und .NET 5 ist in der Preview und ein Paket.
Kann nachinstalliert werden.

Aber: wir lassen das nun bitte mit dem Endlosthread, sonst müssen wir das halt schließen.

Wenn ich das richtig verstanden habe:

Die Kommunikation der Business Schicht mit der GUI erfolgt NUR über Events, ich muss also in meiner neuen Logik Schicht also für alles, was ich mal angezeigt haben will, über ein General-Text-Event gehen und dass dann abfeuern...mit eigenen Parametern natürlich, nämlich den Text usw.

...

Ein Event mußt du nur aus der Business-Schicht werfen, wenn du Änderungen der UI mitteilen möchtest.
Die GUI kann aber ansonsten einfach die Werte aus der Business-Schicht abfragen, per Eigenschaften oder Methoden (d.h. du mußt auch nicht alle Werte, die angezeigt werden sollen, als EventArgs mitgeben).