Laden...

Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte]

Letzter Beitrag vor 13 Jahren 19 Posts 16.787 Views
Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte]

Hi!

Folgendes Problem:

Ich habe eine Form A in deren Code der eine 2te Form aufgerufen wird.


private void button1_Click(object sender, EventArgs e)
{
      FormB window = new FormB();
} 

Nun werden dort Daten eingetragen die ich dann mit FormA.SetData(yxz) wieder an FormA übergebe.

Weiß jemand wie ich den Code von FormA auf die Beendigung von FormB "warten" lassen kann?

Zeige FormB einfach Modal an

neueform.ShowDialog(this)

.ShowDialog()

So einfach kann es sein -.-

Vielen Dank!

Hallo empty.at,

modale Dialoge sind out. Verwende besser das Form.FormClosed-Event.

herbivore

modale Dialoge sind out.

wie kommst du zu dieser allgemeinen aussage? Was ist mit dem Save|OpenFileDialog, PrinterDlg und ähnliches?

mfg Markus

beim eventbasierten programmieren (also immer wenn man mit c# werkelt) sind modale dialoge out, da sie unter anderem den anwender die möglichkeit rauben, das dahinterliegende fenster (also aufrufer) zu verschieben. außerdem kann es bei flalscher handhabung passieren, das der modale dialog hinter der aufrufenden form erscheint. und und und. allgemein ist dieser trend schon zu beobachten, das man von modalen dialogen weggeht, da man das jetzt besser lösen kann.

ok, danke

Hallo markus.bodlos,

die Aussagen war sicher etwas überspitzt formuliert, aber es ist ja nunmal schon seit längerem ein deutlicher Trend weg von modalen Dialogen zu erkennen. JAck30lena hat einige Gründe dafür genannt.

In meinen Augen gibt es auch bei Speicher- oder Druckdialogen keinen Grund, warum diese modal sein müssen, eher im Gegenteil. Wenn ich im Druckdialog schon verschieden Einstellungen vorgenommen habe, und mir dann doch noch ein Tippfehler im zu druckenden Text auffällt, warum soll ich dann auf Abbrechen, um den Tippfehler ändern zu können und dann wieder neu in den Dialog, in dem ich dann alle Einstellungen erneut vornehmen muss? Besser wäre es, wenn ich trotz des geöffneten Dialogs den Text noch korrigieren könnte.

herbivore

ist jetzt hoffentlich keine blöde Frage, aber wie soll man dann etwas vergleichbares zum DialogResult bekommen? Die Events sind ja alle private. Soll man etwa der Form eine Referenz auf eine ErgebnisVariable geben, und dann überprüfen, wann sie sich ändert(nein ich meine nicht in einer Schleife, sondern als "EigenschaftsSetEvent")? das wäre wahrscheinlich nicht sehr guter Style, oder? Wie kann man das jetzt besser lösen? Oft kann eine Form auch nicht weiterarbeiten, solange sie kein Ergebnis erhalten hat. (@ganzes Thema: Das ist aber ein ziemlich neuer Trend, oder? Wo steht das eigentlich? Vor ein Paar Vochen haben alle ShowDialog noch als einzig sinnvolle Lösung angeboten)

Hallo ANSI_code,

Die Events sind ja alle private

Events sind typischerweise public. Private Events machen kaum Sinn. Form.FormClosed ist auf jeden Fall public.

Wie kann man das jetzt besser lösen?

Bessere Ansätze findest du in [FAQ] Kommunikation von 2 Forms

Das ist aber ein ziemlich neuer Trend, oder?

Nein, keineswegs.

Wo steht das eigentlich?

Das muss nirgendwo stehen, sondern dass kann man einfach sehen, wenn man sich anschaut, wie sich Software im Laufe der Zeit entwickelt. Früher waren modale Dialoge viel verbreiteter.

Vor ein Paar Vochen haben alle ShowDialog noch als einzig sinnvolle Lösung angeboten

Also ich schreibe seit ich im Forum bin, dass es bessere Lösungen gibt als modale Dialoge.

herbivore

Also ich schreibe seit ich im Forum bin, dass es bessere Lösungen gibt als modale Dialoge.

das kann ich bestätigen^^

es ist auch viel in den best prctise guidelines davon zu lesen das modal nicht mehr so der renner ist. früher hat man die software sehr restriktiv gehalten. man hat also immer den user gezwungen nach schema f vorzugehen. mittlerweile gewinnt das stichwort "usability" die oberhand. man versucht also den user so viele freiheiten zu geben wie die projektfinanzierung hergibt. usability hat auch in der projektplanung deutlich an bedeutung gewonnen.

ein modaler dialog zwingt den user sich mit diesem dialog zu beschäftigen und das ist bad style.

Hallo Herbivore und JAck30lena,

warum soll ich dann auf Abbrechen, um den Tippfehler ändern zu können und dann wieder neu in den Dialog, in dem ich dann alle Einstellungen erneut vornehmen muss? Besser wäre es, wenn ich trotz des geöffneten Dialogs den Text noch korrigieren könnte.

stimmt natürlich, nervt total wenn man es erst später merkt.

usability hat auch in der projektplanung deutlich an bedeutung gewonnen.

full ack.

ein modaler dialog zwingt den user sich mit diesem dialog zu beschäftigen und das ist bad style.

ich behaupte dass es auch anwendungsbereiche gibt, wo sich der user einfach mit der abarbeitung sofort(!) beschäftigen muss. -> Fehler und Warnungen, zwingende updates, im allgemeinen wesentliche benachrichtigungen gehören meines erachtens sowieso dazu. Das mit den Drucker und Datei dialogen lass ich mir einreden dass man das besser lösen kann 😉

mfg Markus

ich behaupte dass es auch anwendungsbereiche gibt, wo sich der user einfach mit der abarbeitung sofort(!) beschäftigen muss. -> Fehler und Warnungen, zwingende updates, im allgemeinen wesentliche benachrichtigungen gehören meines erachtens sowieso dazu.

^^ genau von dem möchte man sich nun lösen.

wenn eine anwendung einen fehler hat, dann sollte sie dennoch nciht wichtiger sein als das was der user gerade macht.

@updates: es gibt nichts nervigeres wie anwendungen die einem vom arbeiten abhalten. mich nerven schon baloontips die aus dem tray auffloppen... wenn da eine anwendung mit messageboxen kommt um mich wegen eines updates hinzuweisen.. %&#/$%&§!! ^^

im prinzip gibt es eigendlich keinerlei verwendung mehr für modale dialoge. man benutzt sie, weil man es gewohnt ist so zu programmieren und weil es prozedural ist.

überredet 😉

mfg Markus

jetzt soll mich noch einer überzeugen, warum nicht modale Öffnen/Speichern-Dialoge besser wären? 🙂

jetzt soll mich noch einer überzeugen, warum nicht modale Öffnen/Speichern-Dialoge besser wären?

ambivalent... je nach betonung wechselt die aussage um 180°. oder ich bin schon überarbeitet... ^^

Hallo Xqgene,

und ich hatte noch überlegt, ob ich dazu gleich was schreibe. 🙂 Aber dann fand ich, dass das Druckdialog-Beispiel sich so analog auf das Speichern übertragen lässt, dass ich es weggelassen habe. Und wenn das Speichern nicht modal ist, warum sollte es das Laden sein. Natürlich kann man darüber reden, dass man verhindert, dass ein Lade- und ein Speicherdialog gleichzeitig geöffnet ist, aber das hat ja nichts mit modal zu tun.

Im Grund ist es doch sowieso immer das gleiche. Es kann immer sein, dass man während einer Operation, die einen Dialog anzeigt, an irgendeiner anderen Stelle der Anwendung etwas nachschauen oder ändern will. Aber das ist nicht der einzige Grund, auf modale Dialoge zu verzichten ...

Hallo markus.bodlos,

auch wenn du schon über_redest_ bis, versuche ich dich noch zu über_zeugen_. 🙂

Schau dir mal ErrorProvider an. Das ist z.B. eine gute Möglichkeit modale Dialoge (oder MessageBoxen die ja nichts anderes sind, als modale Dialoge) zu vermeiden, wenn in der Anwendung ein Fehler auftritt. Insbesondere wenn in einem Fenster mehrere Fehleingaben vorhanden sind, spart man dem Benutzer viele Klicks, um die Fehlermeldungen zu schließen. Aber es sind ja nicht nur die Klicks, die man den Benutzer spart, denn der Text in einer MessageBox verschwindet ja beim Schließen, ohne dass man ihn wiederbringen kann. Wenn man also beim Korrigieren des Fehlers, die (hoffentlich vorhandenen) Hilfestellungen in der MessageBox nachlesen möchte, geht das nicht mehr.

wo sich der user einfach mit der abarbeitung sofort(!) beschäftigen muss.

Hm, selbst bei einem Fragedialog wie "Ungespeicherte Änderungen. Sollen die Änderungen jetzt gesichert werden? Ja, Nein, Abbrechen" zieht mein Tippfehlerbeispiel von oben.

Ich denke, es bleiben wirklich wenige Stellen, an denen ein modaler Dialog nötig oder auch nur besser ist, als eine alternative Lösung.

herbivore

Hallo zusammen:

hier eine Zusammenfassung meiner Aussagen aus diesen Thread in einem einzelnen Beitrag (inkl. einiger Ergänzungen). Die Kernaussage ist:

Modale Dialoge und MessageBoxen sind out.

MessageBoxen sind ohnehin nur eine - besonders nervige - Spezialform modaler Dialoge.

Wenn man sich Anwendungen unterschiedlichen Alters anschaut, ist schon seit längerem ein deutlicher Trend weg von modalen Dialogen zu erkennen.

Nachteile von modalen Dialogen und MessageBoxen

Modale Dialoge rauben den Anwender unter anderem die Möglichkeit das dahinter liegende Fenster (also den Owner) zu verschieben. Und sie verhindern, dass das dahinter liegende Fenster bedient werden kann. Letzteres mag - wenn man nicht genauer darüber nachdenkt - beabsichtigt sein, ist aber meistens nicht sinnvoll.

In meinen Augen gibt es selbst bei Druckdialogen keinen Grund, warum diese modal sein müssen, eher im Gegenteil. Wenn ich im Druckdialog schon verschieden Einstellungen vorgenommen habe, und mir dann doch noch ein Tippfehler im zu druckenden Text auffällt, warum soll ich dann auf Abbrechen gehen müssen, um den Tippfehler ändern zu können und dann wieder neu in den Dialog, in dem ich dann alle Einstellungen erneut vornehmen muss? Besser wäre es, wenn ich trotz des geöffneten Dialogs den Text noch korrigieren könnte.

Genau das gleiche bei Speicherdialogen, wenn ich mich schon mühsam zum Zielverzeichnis durchgeklickt habe und dann vor dem Speichern doch noch etwas ändern oder einen Fehler korrigieren will. Und wenn das Speichern nicht modal ist, warum sollte es das Laden sein. Natürlich kann man darüber reden, dass man verhindert, dass ein Lade- und ein Speicherdialog gleichzeitig geöffnet ist, aber das hat ja nichts mit modal zu tun.

Selbst bei einem Fragedialog wie "Ungespeicherte Änderungen: Sollen die Änderungen jetzt gesichert werden? Ja, Nein, Abbrechen", bei dem sich der Eindruck aufdrängt, der Benutzer müsse sich sofort mit der Beantwortung und mit nichts anderem beschäftigen, zieht mein Tippfehlerkorrekturbeispiel.

Im Grund ist es doch sowieso immer das gleiche. Es kann immer sein, dass man während einer Operation, die einen Dialog anzeigt, an irgendeiner anderen Stelle der Anwendung etwas nachschauen oder ändern will. Insbesondere bei Einstellungsfenstern finde ich es sehr nervig, wenn diese modal sind (und keinen Übernehmen-Button zum Speichern ohne Schließen haben) und ich die Anwendung deshalb nicht weiterhin bedienen kann, um zu prüfen, wie sich die geänderten Einstellungen auswirken.

Aber das sind nicht die einzigen Gründe, auf modale Dialoge zu verzichten. Dazu muss man natürlich erstmal klären, wozu der modale Dialog dient. Nehmen wir mal das Beispiel der früher sehr verbreiteten und leider immer noch nicht ganz ausgestorbenen MessageBoxen zur Anzeige von Fehlermeldungen.

Insbesondere wenn in einem Fenster mehrere Fehleingaben vorhanden sind, spart man dem Benutzer viele Klicks, um die Fehlermeldungen zu schließen. Man stelle sich vor, in Visual Studio würde beim Compilieren jeder Fehler einzeln als MessageBox angezeigt werden. Aber es sind ja nicht nur die Klicks, die man den Benutzer spart, denn der Text in einer MessageBox verschwindet ja beim Schließen unwiederbringlich. Wenn man also beim Korrigieren des Fehlers, noch mal die Meldung oder die (hoffentlich vorhandenen) Hilfestellungen in der MessageBox nachlesen möchte, geht das nicht mehr.

Die Alternativen

Ganz anders beim ErrorProvider. Das ist eine gute Möglichkeit MessageBoxen und modale Dialoge zu vermeiden, wenn sie zur Anzeige von Fehlermeldungen dienen. Weitere Alternativen sind Fehlermeldungen in der Statusbar anzuzeigen oder, wenn das einem nicht auffällig genug ist, kann man in das eigentliche Form auch ein extra Panel einblenden, so wie das auch viele Browser machen, wenn sie darauf hinweisen, dass ein Plugin fehlt.

Wer behauptet, dass ein solcher Hinweis leichter übersehen werden kann, als eine MessageBox, sollte mal überlegen, wie oft er im tagtäglichen Autopilotenmodus eine MessageBox weggeklickt hat, ohne das wahrzunehmen oder zumindest ohne direkt danach zu wissen, was eigentlich in der MessageBox stand. Außerdem sagt niemand, dass die Alternativen zu MessageBoxen unauffällig gestaltet werden sollen; sie können ruhig so auffällig wie nötig sein.

Aber auch andere Dialoge, wie z.B. Suchdialoge, werden immer häufiger einfach direkt in das Form eingeblendet, wodurch ein Wechsel zwischen der Suchfunktion und dem eigenen Form noch einfacher wird. Zuerst habe ich das beim Firefox gesehen.

Aber selbst wenn ein "Dialog" ein eigenständiges Fenster bleibt, muss er nicht modal sein, nur weil man beim Schließen des Fensters noch weitere Aktionen durchführen will. Zwar kann man bei ShowDialog solche Aktionen einfach direkt hinter ShowDialog aufrufen, was bei Show nicht geht, weil Show nicht auf das Schließen wartet, aber Windows-Forms-Anwendungen schreibt man sowieso besser ereignisorientiert. Um eine Aktion beim Schließen eines Fenster durchzuführen, muss man also nur das Form.FormClosed-Event abonnieren.

In vielen Fällen wird man einfach ShowDialog durch Show ersetzen können, nämlich wenn es keinen oder nur schwache Gründe gab, den Dialog modal zu machen. Wenn zum Beispiel nur bestimmte Aktionen nicht mehr erlaubt sind, dann kann man gezielt nur die zugehörigen Controls disablen (und im Form.FormClosed wieder enablen).

Selbst in Fällen, in denen ohne Komplettieren des Dialogs kein sinnvolles Weiterarbeiten möglich ist - mir fallen da eigentlich nur Anmeldedialoge ein -, sollte man modale Dialoge (im Sinne von Form.ShowDialog) vermeiden. Stattdessen kann man die Elemente des Dialogs (z.B. die Eingabefelder) dort einblenden, wo nach erfolgreicher Anmeldung die normalen Bedienelemente und Inhalte angezeigt werden.

Beispiel: Zugriff auf Freigaben im Windows Explorer. Wenn man an einer Freigabe noch nicht angemeldet ist, erscheint beim Zugriffsversuch ein "Verbinden mit ..."-Dialog zum Anmelden. Es wäre wesentlich praktischer, wenn die Eingabefelder für die Anmeldung an der Freigabe einfach dort eingeblendet würden, wo sonst die Dateiliste erscheint. Das stellt genauso gut sicher, dass man erst auf die Freigabe kommt, nachdem man sich dort angemeldet hat. Wenn man sich aber nur im Dateibaum verklickt hat, kann man, ohne im Dialog "Abbrechen" wählen zu müssen, einfach auf das tatsächlich gewünschte Verzeichnis klicken. Ein modaler Dialog verhindert das direkte Weiterarbeiten.

Fazit

Insgesamt gibt es also viele Gründe, modale Dialoge in die Mottenkiste zu packen. Bessere Alternativen gibt es mehr als genug. Die meisten sind genauso einfach zu implementieren. Und selbst wenn der Aufwand etwas höher wäre, sollten deutlich zufriedenere und produktivere Benutzer Grund genug sein.

Siehe auch

[Snippet] Nicht-modale Abfrage als Alternative für MessageBoxen
Warum tauchen Exceptions an unerwarteter Stelle auf? [=> MessageBox.Show/Form.ShowDialog/Application.DoEvents stören den Ablauf]

Suchhilfe: 1000 Worte