Ich entwickle eine Win-Form-App und ich merkte, dass ich ständig auf Methoden in meiner Elternform zugreifen muss, sagen wir Form1 von einer anderen Klasse, sei es eine Form-Klasse oder nur eine Klasse. Ich habe einige Initialisierer im Konstruktor meines Formulars 1 und daher kann ich keine Instanz von Form1 erstellen. Daher kann ich nicht auf die Methoden von Form1 zugreifen.
Ich denke, das ist eine schlechte Übung. Es gibt jedoch bestimmte Fälle, in denen ich nicht weiß, was ich zum Beispiel für dieses Szenario tun soll. Ich habe eine Klasse namens ProcessData, in der ich eine Methode habe, die eine Datei empfängt, sie Zeile für Zeile liest und die Daten verarbeitet. Jetzt nenne ich diese Methode als einen Thread von meinem Hauptformular Form1. Meine Anforderung ist als der Datenprozess, den ich die Zeile anzeigen möchte, die gerade in einem mehrzeiligen Textfeld in dem Hauptformular Form1 bearbeitet wird.
Bisher hatte ich alles in der gleichen Form1, also benutzte ich einen Delegierten, wie
%Vor%und ich habe dies aufgerufen wie SetText ("text", Label1);
Wenn ich das aber von einer anderen Klasse aus rufe, um Label1 zu beziehen, brauche ich eine Instanz von Form1, aber ich kann sie nicht erstellen. Was ist also die beste Vorgehensweise?
(Ich weiß, ich kann den Text einfach an SetText übergeben und das Steuerelement dort handhaben, aber ich werde das gleiche für eine Vielzahl von Textbox- und Label-Steuerelementen verwenden, die von verschiedenen Klassen aufgerufen werden)
Die Art und Weise, wie ich dies normalerweise tue, besteht darin, dass das untergeordnete Formular Ereignisse offenlegt, die den logischen Aktionen und Ereignissen in diesem Formular entsprechen, zum Beispiel:
%Vor%Die Idee ist, dass die Logik Ihres Elternformulars auf Aktionen auf Ihrem Kindformular reagieren sollte, anstatt auf Aktionen Ihres Elternkindes zu reagieren - versuchen Sie, die Formularlogik so weit wie möglich einzukapseln (aka Trennung von Bedenken).
Auch als Muster sollte es das Eltern- / Aufrufformular sein, das die Marsalling-Aufrufe über InvokeRequired etc an den richtigen Thread weiterleitet als das untergeordnete Formular - dies wird sowieso überflüssig sein, es sei denn, Sie arbeiten daran Hintergrundfäden.
Ihre Klasse sollte Ereignisse auslösen und Ihr Formular sollte die Ereignishandler haben. Dies hält Ihren Formularcode in Ihrem Formular und Ihren Klassencode in Ihrer Klasse. Schön und ordentlich.
Das Anheben von Ereignissen, wie von Kragen und Richard vorgeschlagen, funktioniert und verhindert, dass die Eltern / Kind-Beziehung als eng gekoppelt wird. Wenn Sie jedoch etwas wirklich möchten, sehen Sie sich das Event-Aggregator -Muster an. Es gibt ein nettes Projekt im Prism-Projekt hier , obwohl viele Leute es unpraktisch finden, sie zu benutzen, und Erweiterungen erstellt haben, um die Arbeit mit zB dies zu erleichtern , oder schreiben Sie sich von Grund auf selbst wie dies .
Im Grunde ist die Idee, dass es dem Elternteil nicht einmal wichtig ist, dass die Nachricht aus dem untergeordneten Fenster kommt. Das untergeordnete Fenster hat lediglich eine Nachricht wie "Open Order # 6" auf den Nachrichtenbus geworfen, unter der Annahme, dass jemand anderes damit umgehen wird, so ziemlich wie das Auslösen eines Ereignisses. An anderer Stelle hat das übergeordnete Formular, das für das Enthalten aller untergeordneten Formulare zuständig ist, "Open Order" -Nachrichten abonniert und empfängt daher die Nachricht und öffnet ein neues untergeordnetes Fenster für Bestellung Nr. 6.
Da der Elternteil nicht mehr direkt mit dem Kind "verschweißt" wird, ist es möglich, dass diese Nachrichten auch anderswo entstehen. Sie können "Open Order" -Nachrichten aus einer zuletzt verwendeten Liste im übergeordneten Formular selbst oder als Reaktion auf einen Hyperlink in einer anderen Form, auf den geklickt wird, auslösen. Es spielt keine Rolle mehr, wer gefragt hat, ob der Auftrag Nr. 6 geöffnet werden soll, sondern nur jemand. Es ist ein sehr flexibles Modell, das viele enge Kopplungen eliminiert.