Willkommen auf myCSharp.de! Anmelden | kostenlos registrieren
 | Suche | FAQ

Hauptmenü
myCSharp.de
» Startseite
» Forum
» Suche
» Regeln
» Wie poste ich richtig?

Mitglieder
» Liste / Suche
» Wer ist online?

Ressourcen
» FAQ
» Artikel
» C#-Snippets
» Jobbörse
» Microsoft Docs

Team
» Kontakt
» Cookies
» Spenden
» Datenschutz
» Impressum

  • »
  • Community
  • |
  • Diskussionsforum
Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte]
empty.at
myCSharp.de - Member



Dabei seit:
Beiträge: 152
Herkunft: Österreich

Themenstarter:

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

beantworten | zitieren | melden

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?
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von empty.at am .
private Nachricht | Beiträge des Benutzers
Xqgene
myCSharp.de - Member



Dabei seit:
Beiträge: 2189

beantworten | zitieren | melden

Zeige FormB einfach Modal an
"A programmer is a tool which converts coffein to code."

Evely ToDo-Manager 1.2 (Build 1.2.585)
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

neueform.ShowDialog(this)
empty.at
myCSharp.de - Member



Dabei seit:
Beiträge: 152
Herkunft: Österreich

Themenstarter:

beantworten | zitieren | melden

.ShowDialog()

So einfach kann es sein -.-

Vielen Dank!
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von empty.at am .
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo empty.at,

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

herbivore
private Nachricht | Beiträge des Benutzers
markus.bodlos
myCSharp.de - Member



Dabei seit:
Beiträge: 207
Herkunft: Österreich / Steiermark

beantworten | zitieren | melden

Zitat
modale Dialoge sind out.

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

mfg Markus
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

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.
markus.bodlos
myCSharp.de - Member



Dabei seit:
Beiträge: 207
Herkunft: Österreich / Steiermark

beantworten | zitieren | melden

ok, danke
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers
ANSI_code
myCSharp.de - Member

Avatar #avatar-2839.jpg


Dabei seit:
Beiträge: 486
Herkunft: Bayern

beantworten | zitieren | melden

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)
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

Hallo ANSI_code,
Zitat
Die Events sind ja alle private
Events sind typischerweise public. Private Events machen kaum Sinn. Form.FormClosed ist auf jeden Fall public.
Zitat
Wie kann man das jetzt besser lösen?
Bessere Ansätze findest du in [FAQ] Kommunikation von 2 Forms
Zitat
Das ist aber ein ziemlich neuer Trend, oder?
Nein, keineswegs.
Zitat
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.
Zitat
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
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

Zitat
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.
markus.bodlos
myCSharp.de - Member



Dabei seit:
Beiträge: 207
Herkunft: Österreich / Steiermark

beantworten | zitieren | melden

Hallo Herbivore und JAck30lena,
Zitat
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.
Zitat
usability hat auch in der projektplanung deutlich an bedeutung gewonnen.

full ack.
Zitat
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
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

Zitat
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.
markus.bodlos
myCSharp.de - Member



Dabei seit:
Beiträge: 207
Herkunft: Österreich / Steiermark

beantworten | zitieren | melden

überredet

mfg Markus
private Nachricht | Beiträge des Benutzers
Xqgene
myCSharp.de - Member



Dabei seit:
Beiträge: 2189

beantworten | zitieren | melden

jetzt soll mich noch einer überzeugen, warum nicht modale Öffnen/Speichern-Dialoge besser wären?
"A programmer is a tool which converts coffein to code."

Evely ToDo-Manager 1.2 (Build 1.2.585)
private Nachricht | Beiträge des Benutzers
Gelöschter Benutzer

beantworten | zitieren | melden

Zitat


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... ^^
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

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 überredest bis, versuche ich dich noch zu überzeugen. :-)

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.
Zitat
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
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

beantworten | zitieren | melden

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
private Nachricht | Beiträge des Benutzers