Laden...

Instanzvariable in Form vs. Variable mitgeben [==> weder noch, sondern Events]

Erstellt von ModelViewPresenter vor 11 Jahren Letzter Beitrag vor 11 Jahren 1.820 Views
Thema geschlossen
ModelViewPresenter Themenstarter:in
67 Beiträge seit 2011
vor 11 Jahren
Instanzvariable in Form vs. Variable mitgeben [==> weder noch, sondern Events]

Hallo,

ich habe gerade einen Thread in einem anderem Forum gelesen (http://www.uni-protokolle.de/foren/viewt/294220,0.html)

Zusammengefasst geht es darum, dass eine Form auf eine andere zugreift.

private static FormMain _instance;
public static FormMain Instance {
get {
   if (_instance == null) {
      new FormMain();
   }
   return _instance;
}

Zugriff in einer anderen Form:

FormMain.Instance.Show( msg );

Demgegenüber steht nun, dass man der einen Form die Referenz auf die andere mitgibt, um darauf zugreifen zu können.

Die Argumente der User dort finde ich nicht ganz schlüssig und ich wollte mal wissen, was ihr dazu sagt. Was sind die Vor- und Nachteile?

D
615 Beiträge seit 2009
vor 11 Jahren

Hallo ModelViewPresenter

Das ist wirklich sehr unsauber, und gleicht eher einem Hack der absolut nicht notwendig ist...

Hier gibts ein FAQ Artikel dazu : [FAQ] Kommunikation von 2 Forms

Demgegenüber steht nun, dass man der einen Form die Referenz auf die andere mitgibt, um darauf zugreifen zu können.

Das wäre schon einiges besser. Ich würde die Kommunikation über Events machen (siehe FAQ)

Beste Grüsse

Diräkt

ModelViewPresenter Themenstarter:in
67 Beiträge seit 2011
vor 11 Jahren

Du würdest also für das Anzeigen der einen Form (Show) ein eigenes Event definieren?

Ich verstehe sowieso nicht, warum eine Form überhaupt eine andere aufrufen soll. Kann man sowas nicht besser mit einer Art "Application Controller" umsetzen?

2.298 Beiträge seit 2010
vor 11 Jahren

Meistens übernehmen die Forms die Rolle der View und des Controllers. Damit ist das Hauptformular dann auch MainController.

Wird jetzt z.B. der Informationsdialog im Menü angelegt, ruft auch das MainForm den Dialog auf. Der Dialog wiederum ist Controller für alles was bei ihm passiert.

Auch hat Diräkt nicht gesagt, er würde ein eigenes Event für das zweite Form definieren. Richtiger Weise wollte er ausdrücken: Die MainForm ruft die 2. Form auf. Wurden die Arbeiten in Form2 beendet, wirft diese ein Event, auf das das MainForm reagiert. Dies steht aber auch alles im verlinkten Artikel.

Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager |

ModelViewPresenter Themenstarter:in
67 Beiträge seit 2011
vor 11 Jahren

Mit Application Controller meinte ich das Pattern von Martin Fowler. Das ist kein Controller im MVC-Sinne.

Some applications contain a significant amount of logic about the screens to use at different points, which may involve invoking certain screens at certain times in an application. This is the wizard style of interaction, where the user is led through a series of screens in a certain order. In other cases we may see screens that are only brought in under certain conditions, or choices between different screens that depend on earlier input.

Vermutlich gibt es heute andere/modernere Ansätze für sowas. Ich gebe zu, dass mir diese nicht bekannt sind.

49.485 Beiträge seit 2005
vor 11 Jahren

Hallo ModelViewPresenter,

Zusammengefasst geht es darum, dass eine Form auf eine andere zugreift.

das ist schon etwas arg komprimiert und verschweigt den wesentlichen Aspekt, dass es um den Zugriff des Unterformulars (Form2) auf das Hauptformular (Form1) geht:

Damit das Unter Formular auf das Hauptformular zugreifen kann, wird einen Instanzvariable im Hauptformular auf sich selbst gesetzt und der Unterformular kann auf diese static Valiable zugreifen.

Die Argumente der User dort finde ich nicht ganz schlüssig

Kann ich nicht nachvollziehen, was du daran nicht schlüssig findest. Die wesentlichen Aussagen ...

Warum soll das Unterformular überhaupt auf das Hauptformular zugreifen?
[...]
Üblicherweise greifen Formulare überhaupt nie gegenseitig aufeinander zu. Im Idealfall sollten sie gar nicht kennen.

... kann ich voll unterschreiben, sofern man die zweite Aussage richtig liest, nämlich dass das gegenseitige Zugreifen bzw. Kennen das Problem ist. Ein Kennen/Zugriff in nur eine Richtung, vom Hauptform auf das untergeordnete Form ist unproblematisch. Problematisch ist der Zugriff vom untergeordneten Form auf das Hauptform. So steht es denn auch in [FAQ] Kommunikation von 2 Forms:

Form2 sollte nie auf Form1 zugreifen. Form2 sollte Form1 nicht mal kennen. Das ist auch nie nötig. Stattdessen verwendet man Events (
>
).

Du würdest also für das Anzeigen der einen Form (Show) ein eigenes Event definieren?

Nein, denn das ist ja die unproblematische Richtung von Form1 nach Form2. Das kann durch direkten Aufruf erfolgen.

Und damit habe ich schon weit mehr gesagt, als ich sagen wollte, denn zum einen steht alles in der FAQ und zum anderen ist das letztlich als Crosspost anzusehen. Zwar bist nicht du derjenige, der in zwei Foren gepostet hast, aber du hast eine Frage aus einem aktuell laufenden Thread aus dem einen Forum 1:1 in das andere Forum getragen und damit verursacht, dass in beiden Foren zeitgleich unnötigerweise über das selbe diskutiert wird. In dem anderen Forum wurde die Frage - wie schon gesagt - korrekt beantwortet.

herbivore

Thema geschlossen