Eventhandler nach schließen eines zweiten Fensters

Hallo,

hab ein einfaches (denke ich) Problem, finde aber keine passende Lösung.

Form1 erstellt ein neues Objekt Form2, welches dann mit show fokussiert wird. Wenn ich Form2 nun wieder schließe, möchte ich, dass dies in Form1 mittels Eventhandler abgefangen wird um darauf zu reagieren. OnFocus war am naheliegendsten, funktioniert aber nicht (hab ich mittlerweile auch hier gelesen). OnEnter zündet leider auch nicht.

Vielleicht hat ja jemand von euch eine Idee.

das OnClosed-event des 2. fensters abbonieren und dort reagieren?

Ruf Form2 mit ShowDialog auf, dann gehts in Form1 genau da weiter wo du den Aufruf gemacht hast.

ShowDialog() statt Show() brachte in meinem Fall eine einfache Lösung, da es tatsächlich den Ablauf in Form1 unterbricht und somit auf die Rückkehr aus Form2 mit der Fortsetzung des Ablaufs in Form1 reagiert werden konnte.

Vielen Dank für die schnelle Hilfe ^^

show dialog ist dennoch nciht die optimale lösung, da der user die form1 nicht bewegen/minimieren kann, solange form2 noch offen ist. besser ist es mit den besagten closingevent und enabled properties zu arbeiten.

Naja, ShowDialog() ist schon eine optimale Lösung, es kommt eben drauf an, ob die Kontrolle an die Form2 übergeben werden soll, bzw. Form1 während dieser Zeit nicht weiterbenutzt werden soll.

Falls Form1 weiter aktiv bleiben soll und auch weiter auf Benutzereingaben reagieren soll, dann ist ShowDialog natürlich murks, ansonsten würde ich schon ShowDialog() benutzen.

Das nicht Verschieben/Minimieren hat ja auch einen Grund, So ist immer ersichtlich, wer der Vater des Dialogs ist.

Hallo kinnley, hallo chilic,

Naja, ShowDialog() ist schon eine optimale Lösung

nein, ShowDialog ist - wie JAck30lena sagt - keine gute Lösung und auf jeden Fall nicht mehr zeitgemäß. Siehe dazu auch: Warten auf Schließen einer anderen Form (und warum Dialoge nicht modal machen sollte).

herbivore

Das sehe ich nicht so.
Es gibt eben Situationen in denen ich genau diese Funktionalität wünsche. Natürlich kann ich dieses Verhalten auch in mode-less Fenstern (bzw. im Parent) implemetieren, aber die Frage steht doch da ganz klar im Nutzen/Aufwand.
Ich habe natürlich mehr Flexibilität in mode-less Fenstern und muss mich "als Anwender" nicht mit der Entscheidung des Programmieres rumschlagen, diesen Dialog jetzt und genau jetzt durchzuführen bevor ich auch nur irgendwie was anderes mache, aber deshalb sehe ich ShowDialog() nicht als nicht mehr Zeitgemäß an.

Hallo chrismoe,

Ich habe natürlich mehr Flexibilität in mode-less Fenstern und muss mich "als Anwender" nicht mit der Entscheidung des Programmieres rumschlagen

und genau das wird von den einschlägigen Software-Ergonomie-Vorschriften und -Normen gefordert. Es soll eben dem Benutzer überlassen sein, wie er die Software benutzen möchte (Steuerbarkeit). Er soll sich nicht an die Abläufe halten müssen, die dem Programmierer vorgeschwebt haben.

ShowDialog mag für den Programmierer einfacher sein, aber ich bleibe dabei: Es ist nicht mehr zeitgemäß.

Das nicht Verschieben/Minimieren hat ja auch einen Grund, So ist immer ersichtlich, wer der Vater des Dialogs ist.

Das ist eine gewagte Argumentation. Es würde - wenn schon ShowDialog - vollkommen reichen, wenn bei einem Klick auf den Elternfenster das Kindfenster aktiv werden würde, um den Zusammengang zu verdeutlichen. Dass das Elternfenster nicht verschiebbar ist, ist dagegen einfach nur störend und nicht mehr zeitgemäß. Es ist daher ein weiteres Argument gegen ShowDialog.

herbivore

und genau das wird von den einschlägigen Software-Ergonomie-Vorschriften und -Normen gefordert. Es soll eben dem Benutzer überlassen sein, wie er die Software benutzen möchte (Steuerbarkeit). Er soll sich nicht an die Abläufe halten müssen, die dem Programmierer vorgeschwebt haben.
herbivore

Undwie genau soll das dann ausehen? Ich stell mir gerade unsere Applikation vor, die der Kunde komplett selber steuert - mit 50 mode-less Fenstern auf, die der Kunde dann schön in beliebiger Reihenfolge abarbeitet und bei spätestens 5 vergessen hat, was er machen wollte. Die Software kann natürlich so designt werden und die Informationen könnten dem Kunden auch in übersichtlichen kleinen Tasks dargestellt werden aber eine allgemeine Aussage wie "Modal ist veraltet" sollte da diferenzierter gesehen werden. Nach meiner Erfahrung ist der simple Anwender oft froh, wenn er modal irgendwo durchgeführt wird.
Ich gebe dir recht, dass es sicher besserer Lösungen gibt ein quasi-modales Fenster mode-less zu integrieren für eben diese Tasks. Aber modale Fenster als nicht mehr zeitgemäß zu beschreiben, nur weils der Ergonomie-Experte so sieht, ist mir etwas dünn.

Hallo chrismoe,

Ich stell mir gerade unsere Applikation vor, die der Kunde komplett selber steuert - mit 50 mode-less Fenstern auf, die der Kunde dann schön in beliebiger Reihenfolge abarbeitet und bei spätestens 5 vergessen hat, was er machen wollte.

nun werd mal nicht albern. Erstmal haben die meisten Anwendungen schonmal gar nicht soviele Fenster und selbst wenn eine Anwendung soviele Fenster hätte, dann würde gerade die unsicheren Anwender nicht ein Fenster nach dem anderen offenlassen, sondern jedes Fenster so schnell wie möglich schließen, um nicht den Überblick zu verlieren. Außerdem spricht nichts dagegen, für neue und unbedarfte Anwender Assistenten einzubauen, die eine feste Abfolge anbieten. Es spräche sogar nicht mal etwas gegen einen Anfängermodus, in dem nur die Assistenten zugänglich sind, solange dieser sich abschalten lässt.

Davon ganz angesehen, habe ich nicht behauptet, dass die Alternative zu ShowDialog zwangsläufig Show ist. Es gibt viele andere Möglichkeiten. So wird z.B. beim Firefox der Suchdialog durch das Einblenden von Steuerelementen in das Hauptfenster ersetzt. MessageBoxen (die ja auch modal sind) können durch Statusleisten oder ErrorProvider ersetzt werden. Es gibt da unzählige Möglichkeiten.

Wenn man sich erstmal von ShowDialog verabschiedet hat, tun sich ganz neue Perspektiven auf. Bei den Alternativen bin ich gerne bereit, die Sache differenzierter zu sehen, aber an "Modal ist veraltet" halte ich absolut fest.

herbivore

Hallo,

auch wenn das Ganze mittlerweile mehr eine Grundsatzdiskkusion ist - und damit woanders hingehört - als daß eine Lösung der ursprünglichen Frage eruiert wird...

Modal ist veraltet, sehe ich auch so. Dennoch mag es Anwendungsbeispiele geben, bei welchen es durchaus noch empfehlenswert ist, einen Modalen Dialog anzubieten. Interessanterweise gibt es gerade in Webanwendungen ein bisschen so den Trend, sowas wie modale Dialoge einzubinden: mittels CSS (?) wird eine Eingabe angefprdert und der Rest der Seite wird ausgegraut/deaktiviert.
Man sollte also - meines Erachtens - den konkreten Anwendungsfall betrachten.

und genau das wird von den einschlägigen Software-Ergonomie-Vorschriften und -Normen gefordert

Aus unerfindlichen Gründen musste ich hier an Knigge denken: Während vor nicht allzu langer Zeit ein 'Gesundheit' als Reaktion auf ein Nießen geraten wurde, ist genau dieses nun nicht mehr salonfähig, weil der angesprochene dadurch auf seinen 'Makel' auch noch hingewiesen wird. 🤔
Will sagen: Software-Ergonomie-Vorschriften 'leben' und das was heute noch gefordert wird, kann morgen schon abgelehnt werden.

Also wenn ich dich richtig verstehe, wehrst du dich gegen den Gedanken, dass die Parent-Form in irgendeinerweise duch das Einbleden einer zweiten Form, nicht mehr zugreifbar ist? Und das eben dieses Verhalten veraltet ist, weil man es auch anderes lösen könnte?
Usability/Ergonomie-Grüde also?

Tut mir leid aber nach diesem Standpunkt könnte man dann ja so ziemlich alles als veraltet bezeichnen.
Aber ich muss meinem Vorposter zustimmen, Grundsatzdiskussionen führen ja meistens zu nix 😉

Hallo KenchU,

Will sagen: Software-Ergonomie-Vorschriften 'leben' und das was heute noch gefordert wird, kann morgen schon abgelehnt werden.

ich habe nie gesagt, dass es anders ist. Aber momentan ist es eben so, wie ich beschrieben habe. 😃

Hallo chrismoe,

Tut mir leid aber nach diesem Standpunkt könnte man dann ja so ziemlich alles als veraltet bezeichnen.

diese Schluss kann ich beim besten Willen nicht nachvollziehen. Veraltet sind modale Dialoge unter anderem deshalb, weil modale Dialoge in neueren Anwendungen immer seltener benutzt werden. Sie werden immer mehr durch andere und in meinen Augen bessere Konzepte ersetzt. Ich habe hier und in dem anderen Thread verschiedene Gründe angegeben und auch konkrete Szenarien bekannt, aus denen hervorgeht, dass man modale Dialoge besser nicht mehr verwenden sollte. Deine Argumente für modale Dialoge habe ich widerlegt. Das alles bezog sich konkret auf das Thema modale Dialoge. Es lässt sich keineswegs auf alles andere übertragen.

herbivore

Tut mir leid, ich sehe modale Fenster eben nicht aus den Gründe, die du gennant hast, als veraltet an.
Und mit "sich auf alles andere" beziehen, meinte ich eigentlich die Herleitung der Argumentation deinerseits. Nach dieser Argumentation kann man COM als veraltet ansehen (was viele auch tun) und dennoch gleiche Bauchscmerzen bei mir auslöst, weil man es eben in vielen Fällen nicht so einfach abtuen kann.

COM ist veraltet. Punkt. Es gibt Technologien, die COM ersetzt haben. Heute noch in ein neues Programm COM einzubauen ist in etwa so, wie wieder ein 14.4er Modem einzusetzen, wo man einen DSL-Anschluss hat.
Etwas anders sieht es bei Modal aus. Ich würde auch immer drauf verzichten, wenn ein anderes Konzept für eine Anforderung mindestens genausogut passt. Ob es immer ein anderes Konzept gibt, ist eine ganz andere frage...

Ich denke auch dass diese Grundsatz-/Geschmacksdiskussion nicht hierhingehört.
Da ShowDialog allerdings in der API nicht als deprecated markiert ist und auch keine Warnung kommt wenn man's benutzt, sehe ich keinen Grund, die Funktion nicht zu verwenden oder jemandem ein schlechtes Gewissen einzureden wenn er es tut, wenn sie denn das gewünschte Verhalten erzeugt. Wieso kompliziert (zumal der Fragesteller der Frage nach noch nicht so viel Erfahrung mit dem Programmieren hat) wenns auch einfach geht?

gruß
sth_Weird

Wieso kompliziert (...) wenns auch einfach geht?

die frage müsste heißen: "wieso schlecht, wenn es auch besser geht?" ... natürlich ist dabei die gemeinte aussage verdreht.

das, was einen modalen dialog ersetzt ist in diesem fall ein .Show + .Enabled = false + FormClosing+=myeventhandler

-> 3 simple sachen und die form1 ist verschiebbar und blockiert keine anderen anwendungen, wo man sich evtl texte herauskopieren möchte uvm...

und wenn 90% denken, das COM veraltet ist, kann man davon ausgehen das die verbleibenden 10% nicht recht haben. sogar microsoft sagt, das com veraltet ist und spätestens dann sollte man sich über seine einstellung dazu gedanken machen.

Ich weiß meine Ellis würden durchdrehen, wenn der Drucken-Dialog bei Word nicht modal wäre und er dann evtl im Hintergrund verschwinden würde

tja. man kann durch falsches hantieren und schlechten code den modalen dialog dazu bringen hinter der form zu erscheinen und in der taskleiste nicht sichtbar zu sein.... DAS ist ergonomisch unverträglich (auch für erfahrene benutzer eine harte nuss), da du ja ncihtmal den parent verschieben kannst....

verschieben eines fensters ist in meinen augen ein fundamentes feature, das jede anwednung zu jedem zeitpunkt (fullscreen anwendungen ausgenommen) ermöglichen sollte.

Also die Argumentation gegen modale Fenster find ich schon etwas unüberlegt.

Natürlich gibts Abläufe bei denen man irgendwas parallel machen oder ansehen kann. Aber es gibt halt auch vieles was geregelt werden muss. Damit zwingt man den Benutzer zu nichts, man hilft ihm. Es sitzen nicht lauter Spezialisten vor dem PC, die wissen warum sie auf einmal zwei Fenster offen haben.

Stellt euch mal vor der Druckeinstellungendialog ist offen und der Druckdialog auch. Was passiert jetzt wenn man wann wo drauf drückt? Wird so gedruckt wie es eingestellt ist? Oder erst dann so wie eingestellt, wenn mans auch übernimmt? Was wenn man Murks einstellt und es abbrechen will?
Wer kapiert das noch, oder anders gesagt wie viele Hotlinetelefone könnt ihr gleichzeitig bedienen?
Von der Komplexität des Codes mal ganz abgesehen.

Wenn ich ein Fenster grad mal nicht mininieren kann, dann bedeutet das ja vielleicht eben gerade dass ich ein anderes vorher beachten und fertig bearbeiten soll.

wenn eine anwendung einen fehler hat, dann sollte sie dennoch nciht wichtiger sein als das was der user gerade macht.
Doch natürlich, spätestens kritische Fehlermeldungen gehören so auf den Bildschirm dass man außer ihnen nichts anderes mehr sieht und auch nichts anderes mehr bedienen kann.
Es gibt wenig schlimmeres, als dass jemand mit einem zerschossenen Programm/Zustand weiterarbeitet und nicht ausdrücklich gesagt kriegt dass grad alles den Bach runter geht.

Hallo sth_Weird,

Ich denke auch dass diese Grundsatz-/Geschmacksdiskussion nicht hierhingehört.

doch. Der OP wollte entsprechend des Titels wissen, wie er einen "Eventhandler nach schließen eines zweiten Fensters" ausgeführt bekommt. Er wollte es also von vorne herein richtig machen. Als Workaround wurde dann leider ShowDialog angeboten, was der OP - ebenfalls leider - bereitwillig akzeptiert und übernommen hat. Dann gehört die Diskussion, warum ShowDialog eine schlechte Lösung ist und er stattdessen besser das verwenden sollte, wonach er korrekterweise ursprünglich gefragt hatte, unmittelbar zum Thema. Es ist eine Diskussion um die beste Lösung, wie man das Schließen eines untergeordneten Fensters mitbekommt.

... sehe ich keinen Grund ...

Zumindest habe ich x gute, relevante und praxisnahe Gründe genannt.

Wieso kompliziert (zumal der Fragesteller der Frage nach noch nicht so viel Erfahrung mit dem Programmieren hat) wenns auch einfach geht?

Einen Closed-EventHandler zu verwenden, ist überhaupt nicht kompliziert. Im Gegenteil, es ist genau die Art von ereignisgesteuerter Programmierung, die man in Windows-Forms dauernd (und sinnvollerweise) verwendet. Jeden simplen Button-Click behandelt man so. Man muss also überhaupt nicht umdenken. Auch als Anfänger nicht.

... wenn der Drucken-Dialog bei Word nicht modal wäre und er dann evtl im Hintergrund verschwinden würde ...

Du musst ja nicht von einem Extrem ins andere fallen. Ich habe was gegen modale Dialoge gesagt. Ich habe nichts dagegen gesagt, eine Owner-Beziehung zu setzen, durch die ein untergeordnetes Fenster immer vor dem Hauptfenster bleibt. Oder wie beim Firefox, wo die Steuerelemente, die sonst im Dialog wären, einfach in das Hauptfenster eingeblendet werden. Auch da könnte nichts hinter das Hauptfenster rutschen. Es ist also keineswegs zwangsläufig so, dass man durch einen "Verzicht" auf modale Dialoge, keine anfängertaugliche Software schreiben kann. Im Prinzip hast du mit der Gegenüberstellung "Anfänger" - "Experte" genau den wichtigsten Grund genannt, warum die Software die Arbeitsreihenfolge nicht unverrückbar vorgeben sollte: Weil die Anwender unterschiedlich und eben nicht alle Anfänger sind. Und im Zweifel können die Anfänger immer noch einen Anfängermodus bekommen.

Hallo chrismoe,

durch deinen COM-Vergleich hast du dich natürlich der akuten Gefahr ausgesetzt, als ewig Gestriger angesehen zu werden, der dann natürlich auch bei modalen Dialogen nicht vom alteingesessenen abgehen will. 😃

Hallo chilic,

Also die Argumentation gegen modale Fenster find ich schon etwas unüberlegt.

keine Ahnung, wie du zu diesem Eindruck kommst. Wenn du nochmal genau liest, dann siehst du, dass alles berücksichtigt wurde. Du blickst im Gegenteil nur auf eine Anwendergruppe, die Anfänger und siehst eben nicht, dass eine Software allen Benutzergruppen, also auch den Experten, Rechnung tragen sollte. Wie man beides - auch ohne modale Dialoge - vereinbaren kann, habe ich nun schon mehrfach aufgezeigt.

Stellt euch mal vor der Druckeinstellungendialog ist offen und der Druckdialog auch. Was passiert jetzt wenn man wann wo drauf drückt? Wird so gedruckt wie es eingestellt ist? Oder erst dann so wie eingestellt, wenn mans auch übernimmt?

Also ich finde das wirklich einfach und eindeutig zu entscheiden. Wenn es - wie üblich - in den Fenstern einen OK-(und Abbrechen-)Button gibt, dann gelten die Änderungen in einem Dialog erst für den Rest der Anwendung, wenn der OK-Button betätigt wurde. Bis dahin gelten die bisherigen Einstellungen.

Davon abgesehen spricht nichts dagegen, im Anfängermodus das gleichzeitige öffnen beider Druckfenster zu verhindern. Und schon sind alle Benutzergruppen - ganz ohne modale Dialoge - glücklich.

Hallo zusammen,

ich bin echt etwas bedrückt, was hier für konservative, um nicht zu sagen innovationsfeindliche Positionen vertreten werden. Für mich ist der Fall klar: ShowDialog (= modale Dialoge) gehört in die gleiche Mottenkiste, in die auch ArrayList (die ebenfalls nicht als deprecated markiert ist) gehört.

Wie dem auch sei. Ich denke, so langsam sind alle Argumente getauscht und jeder kann sich selbst eine Meinung bilden, wie er es halten will.

herbivore

Hmm, wenn modale Dialoge die Useability einer Anwendung so signifikant herabsetzen, warum hat sich dann noch keiner über das umständliche Datei-anhänge-Verfahren von myCsharp beklagt? (Oder gabs die Klage schon?)
Da muß man einen Button klicksen, und dann poppt ein neuer Browser auf, und da muß man nochmal auf einen button klicksen, und dann kriegt man einen modalen (!) File-Search-Dialog - ist das modern?
Ergonomisch wäre doch, wenn ich aussm Explorer meine Dateien ins Textfeld ziehen könnte, und drinne wären sie. Abers stört mich nicht die Bohne, weil verwende ich vlt zweimal pro Woche, und ich bin wirklich ein fleißiger Anhang-Poster.

Und groß Priorität würde ich dem auch nicht einräumen. Wenn ich inner Entwicklung an einer Stelle eine Datei-Eingabe brauche, dann nehmich halt den FileOpen-Dialog, und mach weiter. Das kannich jederzeit umbauen, und mir Gedanken machen, wie ich da temporäre Panel aufpoppen lasse, und dabei den Rest der Anwendung ausgraue oder was.

son FileOpen-Dialog ist quasi quick, aber nicht dirty.

Weil versaut nicht das Programm-Design, und ist ja auch keine Basis, auf die was aufgebaut wird (was normalerweise an q&d problematisch ist).

Äh, versteht mich nicht falsch: Ich will niemandem ausreden, seine Anwendung wirklich schick zu machen, und wenner seine Prioritäten anders liegen hat als ich (Aussehen ist mir schnuppe, praktisch musses sein) - naja, findich schon doof, wenn Schnickschnack eingebaut wird, der mit schlichteren Mitteln ergonomischer wäre (ich denke an diese bescheuerten Bilder-Auswahl-Karrussellse, die im ASP-Net grassieren) - man ist ja nicht gezwungen, jedenfalls nicht immer...

ich bin echt etwas bedrückt, was hier für konservative, um nicht zu sagen innovationsfeindliche Positionen vertreten werden. Für mich ist der Fall klar: ShowDialog (= modale Dialoge) gehört in die gleiche Mottenkiste, in die auch ArrayList (die ebenfalls nicht als deprecated markiert ist) gehört.

Ich finde es sehr gewagt, Leute als konservativ und innovationsfeindlich zu bezeichnen, nur weil sie kein Problem mit modalen Dialogen haben. Man sieht an den unterschiedlichen Meinungen in diesem Thread ja deutlich, dass die Einstellung zu modalen Dialogen auseinandergeht, es letztendlich also doch Geschmacksache ist, was man an dieser Stelle verwendet. Denn ein Entwickler, der sich selbst an einer Funktionsweise anderer Programme, wie modalen Dialogen, stört, wird es sicher in seinem eigenen Programm anders machen. Dem ist aber scheinbar nicht so. Wenn denn genau das Verhalten gewünscht ist, dass ShowDialog ohne Mehrkosten erzeugt, warum es dann umständlich anders implementieren? Wenn ich das darunterliegende Fenster mit Enabled=false deaktiviere (wie von JackOLena vorgeschlagen) habe ich ja auch nichts anderes erreicht, denn ich kann auch im darunterliegenden Fenster weder editieren noch was rauskopieren. Und dann wenn ich die Form schließe aktiviere ich das Fenster durch ein Event wieder. Sorry, aber wo ist da der Vorteil und nach außen hin der Unterschied, als wenn ich ShowDialog verwendet hätte?
Profimodus, Anfängermodus...nuja wenn sich kaum einer daran stört dass modale Dialoge verwendet werden, wird kaum ein Auftraggeber oder Kunde mehr Zeit und Geld investieren, um zwei Modi zu implementieren, die zum gleichen Ergebnis führen...

Bei der ArrayList ist es was anderes. Da gibt es was verbessertes, das sich quasi genauso verhält, nur besser ist. Ich dachte die wäre als deprecated markiert, hatte wohl aber Java im Hinterkopf. Bei ShowDialog gibt es als Alternative aber nur ein anderes Verhalten, was man in vielen Fällen nicht möchte, oder man muss das Verhalten von ShowDialog händisch nachimplementieren, was ich aber ziemlich bescheuert finde.

gruß
sth_Weird

Hallo ErfinderDesRades,

ich finde den Dateianhangvergleich aus verschiedenen Gründen unpassend. Erstmal reden wir hier über Windows-Forms-Anwendungen, nicht über Web-Anwendungen. Das hat in konkreten Fall inbesondere den Effekt, dass nicht die Forensoftware entscheidet, ob der Dialog modal ist oder nicht, sondern der verwendete Browser. Und dann ist es natürlich leicht zu sagen, dass einen etwas nicht stört, was man nur selten benötigt. Ich sterbe auch nicht gleich beim jedem modalen Dialog, aber grundsätzlich sehe ich modale Dialoge als unnötige und unzeitgemäße Einschränkung.

Hallo sth_Weird,

Wenn denn genau das Verhalten gewünscht ist, dass ShowDialog ohne Mehrkosten erzeugt, warum es dann umständlich anders implementieren?

meine ausführlich begründete These ist, dass das Verhalten (bei moderner Software) nicht erwünscht ist.

Bei der ArrayList ist es was anderes. Da gibt es was verbessertes, das sich quasi genauso verhält, nur besser ist.

Bei ShowDialog ist es eben nicht anders. Bezogen auf den konkreten Fall in dem Thread gibt es das Closed-Event. Löst das Problem besser, ohne dass sich für den Programmierer was wesentliches ändert. Nur dass der Benutzer nicht mehr unnötig eingeschränkt ist.

herbivore

Wenn ich das darunterliegende Fenster mit Enabled=false deaktiviere (wie von JackOLena vorgeschlagen) habe ich ja auch nichts anderes erreicht, denn ich kann auch im darunterliegenden Fenster weder editieren noch was rauskopieren.

wenn ich etwas aus der selben anwendung in einen modalen dilog kopieren muss ist die anwdnung ohnehin schon schlecht genug... da stört ein modaler dialog auch nciht mehr.

das was ich eigendlich meinte, war die verschiebefähigkeit des dahinterliegenden fenster (parents). so und nciht anders habe ich es nun schon mehrere male erklärt und es ist mir nachwievor unbegreiflich, das mir die worte immernoch umgedreht werden und der offensichtliche vorteil so vielen leuten verschlossen belibt.

Ich darf ich auch nochmal melden.

Ich habe schon wahrgenommen dass das verschieben ein Grund, um nicht zu sagen der Hauptgrund ist. Grad deswegen versteh ich es ja echt nicht 😉
Daten kopieren, ok. In vereinzelten Fällen ist das vielleicht wirklich ein Manko. Aber in den meisten Dialogen nicht.
Wo ich euch auch recht geben muss ist, wenn ein modaler Dialog zum längeren Arbeiten offen steht. Dann ists ein Designfehler.
Aber es gibt eben trotzdem den klassischen Dialog, den man relativ schnell wieder schließt. Muss mann in dieser Zeit unbedingt das Hauptfenster verschieben können?

Ich denke auch an den Aufwand und die Fehleranfälligkeit bei der beschriebenen Vorgehensweise. Vor allem der Eventhandler den ich aufrufen muss und der mir an einer ganz anderen Stelle im aufrufenden Code weitermacht, als da wo ich eigentlich hergekommen bin und den Dialog auswerten will.
Das tut ihr euch wirklich an, nur damit man während des Dialogs (den man normalerweise relativ schnell wieder schließt) unbedingt das Hauptfenster verschieben kann?

wenn man einen modalen dialog erscheinen lässt, dann verlangt man vom user eine sofortige barabeiteung eines bestimmten zustandes. das an sich ist ja ncihts schlimmes, nur verlangt man eine eingabe, die der user unter umständen gerade eben nciht liefern kann (muss evtl einen kollegen fragen, der aber beschäftigt ist oder aber er will erstmal was anderes fertigmachen usw.... gründe gibt es tausende) und wenn er dann das meist viel größere hauptfenster nciht minimieren kann oder verschieben kann, dann ist das äußerst frustrierend.

Das tut ihr euch wirklich an, nur damit man während des Dialogs (den man normalerweise relativ schnell wieder schließt) unbedingt das Hauptfenster verschieben kann?

jap. das ist unser täglich brot, das geht mir mittlerweile sehr leicht von der hand, das es kaum noch einen unterschied macht.

Vor allem der Eventhandler den ich aufrufen muss und der mir an einer ganz anderen Stelle im aufrufenden Code weitermacht, als da wo ich eigentlich hergekommen bin und den Dialog auswerten will.

event driven development.

ich finde den Dateianhangvergleich aus verschiedenen Gründen unpassend. Erstmal reden wir hier über Windows-Forms-Anwendungen, nicht über Web-Anwendungen.

hmm. Wenn etwas in einer WinForm-Anwendung eine unerwünschte Einschränkung sein soll, wieso in einer WebAnwendung dann nicht?

Das hat in konkreten Fall inbesondere den Effekt, dass nicht die Forensoftware entscheidet, ob der Dialog modal ist oder nicht, sondern der verwendete Browser. Ja, in die Richtung täte ich das auch einschränken, nämlich, dass ein DateiUpload technisch in anderer Form gar nicht möglich ist, ich glaub aus Sicherheitsgründen.
Aber trotzdem ist das myCSharp-DateiUploading eigentümlich und suboptimal. Dass man sich da durch 2 Dialoge klicksen muß, ist bestimmt unnötig. Und von daher ist das Beispiel nicht so unpassend, weil ich ja auf die Prioritäten hinauswollte, ob man da nun in eine ergonomischere Lösung investieren will, ob man noch was anderes zu tun hat, oder sich einfach die Faulheit erlaubt, weil es eh niemanden stört, und letzteres scheint ja zuzutreffen.
Und dann ist es natürlich leicht zu sagen, dass einen etwas nicht stört, was man nur selten benötigt.

Wie gesagt, das ist der Punkt. Modale Dialoge hängen ja rel. häufig in Ecken rum, wo sie selten gebraucht werden, wos also nicht groß stört.
Und grad einen FileOpenDialog unmodal zu machen, stell ich mir nicht so einfach vor. Oder Konfigurations-Dialoge mit massen an Einstellungen.
Ob man da nun das nötige mehr an Aufwand investieren will.

Ich sterbe auch nicht gleich beim jedem modalen Dialog, aber grundsätzlich sehe ich modale Dialoge als unnötige und unzeitgemäße Einschränkung.

Jo, da widerspreche ich dir nicht mal richtig, modale Dialoge sind eingeschränkt. Und das ist an verschiedenen Stellen mal mehr oder weniger schlimm.
Und unmodale Alternativen sind halt mehr oder weniger aufwändig.
Und manchmal trifft die modale Einschränkung recht gut, was man grade braucht, zB ein LogIn-Dialog oder "Speichern-als".

Hallo ErfinderDesRades,

da ich den Vergleich mit dem Dateianhang wie gesagt deplatziert finde, unter anderem weil er auf "Da gibt es eine Software eines bestimmten Anbieters, die (auch wegen eines modalen Dialoges) an einer bestimmten Stelle umständlich/unpraktisch zu bedienen ist, also kann man ruhig auch alle andere Software so schreiben, dass sie umständlich/unpraktisch zu bedienen ist" hinausläuft, gehe ich nicht weiter darauf ein, obwohl ich dir in keinem der Punkte zustimmen kann.

Hallo chilic,

Aber es gibt eben trotzdem den klassischen Dialog, den man relativ schnell wieder schließt. Muss mann in dieser Zeit unbedingt das Hauptfenster verschieben können?

das verschieben den Hauptfensters ist nur ein Grund unter vielen. In dem anderen Thread habe ich beschrieben, warum es mich auch bei Dialogen wie "Drucken" oder "Speichern" nervt, wenn diese modal sind:

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?

Außerdem finde ich, dass die Hauptanwendung immer(!) - mindestens in einem readonly-Modus - bedienbar bleiben sollte, damit der Anwender Informationen nachschlagen kann, die er benötigt, um im Dialog die passenden Angaben machen zu können. Damit meine ich nicht, irgendwelche Angaben per Copy und Paste aus der Hauptanwendung zu übernehmen, sondern z.B. bei geöffnetem Speicherdialog die Eigenschaften der zu speichernden Daten einsehen zu können, um ein Laufwerk auswählen zu können, auf dem noch genug freier Speicherplatz ist. Also mir geht es dauernd so, dass ich um gute Entscheidungen in einem Dialog zu treffen, Informationen aus anderer Stelle der Anwendung benötige. Und wenn der Dialog modal ist, kann ich das eben nicht.

Vor allem der Eventhandler den ich aufrufen muss und der mir an einer ganz anderen Stelle im aufrufenden Code weitermacht, als da wo ich eigentlich hergekommen bin und den Dialog auswerten will.

Wie schon gesagt, ist das der standardmäßige Aufbau einer Windows-Forms-Anwendung. Diese besteht im Grund nur aus EventHandlern, die als Reaktion auf das entsprechende Ereignis ausgeführt werden. Und gerade im konkreten Fall, ist es doch vollkommen egal, ob der Code hinter dem ShowDialog oder im Closed-EventHandler steht. Im "schlimmsten Fall" muss man einige lokale Variablen zu Instanzvariablen machen, aber selbst das ist nicht gesagt.

Hallo zusammen,

ich finde, es ist keine Geschmackssache. Es wird hier zerredet, was für mich offensichtlich ist: ShowDialog hat ausgedient und gehört in die Mottenkiste. Die Zeit der modalen Dialoge ist vorbei. Es gibt wesentlich bessere Ansätze, die man jederzeit verwenden kann, ohne dass der Aufwand (nennenswert) steigt. Wer gute und moderne Software schreiben will, sollte sich von ShowDialog verabschieden.

herbivore

Hallo ErfinderDesRades,
... weil er auf "Da gibt es eine Software eines bestimmten Anbieters, die (auch wegen eines modalen Dialoges) an einer bestimmten Stelle umständlich/unpraktisch zu bedienen ist, also kann man ruhig auch alle andere Software so schreiben, dass sie umständlich/unpraktisch zu bedienen ist" hinausläuft, ...

No, so blöd kann ich mich nicht ausgedrückt haben, dass man mich so falsch verstehen kann. Ich hab von Prioritäten gesprochen, und wenn in irgendwelchen Nischen Bedienbarkeit (noch) nicht vollständig aus-perfektioniert ist, dann "stört das keinen großen Geist" (Astrid Lindgren: Karlson vom Dach). (Trotzdem ist weitere Perfektionierung natürlich immer willkommen.)
Ich bin überhaupt absolut und strikt für Ergonomie, modale Dialoge dürfen bei mir maximal ein Nischen-Dasein fristen. Ich bin vor längerer Zeit sogar ziemlich angefahren worden, weil ich mich abfällig über unergonomisch eingesetzte modale Dialoge geäußert habe: Vorüberlegung zur Form2Form-Kommunikation: Programm-Design überdenken

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?

Also ein im Designer implementierter DruckDialog merkt sich die Einstellungen, da macht das nicht viel aus, den wegzuklicksen.