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

Nenne deinen Fall, wo du denkst, ohne modalen Dialog geht es nicht, und ich nenne eine Alternative
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

Nenne deinen Fall, wo du denkst, ohne modalen Dialog geht es nicht, und ich nenne eine Alternative

beantworten | zitieren | melden

Hallo zusammen,

aufgrund meines Nachdenkens in Modale MessageDialoge in der Anwendung - wann?, bin ich nun mehr der Meinung, dass es keinen Fall gibt, in dem modale Dialoge sinnvoll und notwendig sind. Ich bin im Gegenteil der Meinung, dass es immer eine bessere, benutzerfreundliche und gleichzeitig verständlichere Alternative gibt. Deshalb habe ich diesen Thread erstellt. Ich stelle mich der Herausforderung, dass vielleicht doch jemand einen Fall hat, für den ich keine gute Alternative finde. Andersherum möchte ich jedem, der wirklich an Alternativen interessiert ist, die Möglichkeit geben, sich von mir (und gerne auch von anderen Helfern) diese Alternativen aufzeigen zu lassen.

Da ich mich mit Web- und WPF-Anwendungen nicht so gut auskenne, beschränke ich die Anfragen auf Windows Forms, obwohl ich davon ausgehe, dass es auch für andere Anwendungsarten immer eine Alternative gibt. Fälle, die nicht Bezug auf die speziellen Möglichkeiten einer bestimmen Oberflächentechnologien nehmen, sind ebenfalls ok. [EDIT]Es geht hier also um normale Desktop-Anwendungen.[/EDIT]


In Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte] habe ich bereits einige Gründe gegen modale Dialoge beschrieben und gleichzeitig für die gängige Fälle - insbesondere für MessageBoxen - Alternativen aufgezeigt. Und in [Snippet] Nicht-modale Abfrage als Alternative für MessageBoxen habe ich exemplarisch eine Alternative für einen "Vorm Schließen noch speichern?"-Dialog umgesetzt.


Doch nun zu den konkreten Fällen. Lucy von den Peanuts würde sagen "The Doctor is [span=white]in[/span]". :-) Um zu demonstrieren, wie ich mir das vorstelle, wähle ich ein Beispiel von Abt, was aber auch jeder andere hätte einwerfen können:
Den modalen "Verbinden mit ..."-Dialog, der im Windows Explorer erscheint, wenn man im Dateibaum auf eine Freigabe kickt, an der man noch nicht angemeldet ist. Wie könnte man das ohne modalen realisieren Dialog (besser) realisieren (z.B. wenn man einen eigenen Explorer programmiert)?
Zunächst sind wir uns einig, dass ein Zugriff auf die Freigabe nicht möglich sein soll, solange die Anmeldung noch nicht erfolgt ist. Das bedeutet aber nicht, dass ein modaler Dialog benötigt wird. Und es bedeutet nicht, dass es keine anderen Aktionen gibt, die man trotz der laufenden Anmeldung sinnvoll ausführen kann.

Es wäre praktischer und mindestens genauso verständlich, wenn die Eingabefelder und die Buttons für die Anmeldung an der Freigabe einfach dort eingeblendet werden, 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" klicken zu müssen, einfach auf das tatsächlich gewünschte Verzeichnis klicken. Ein modaler Dialog würde das direkte Weiterarbeiten verhindern.

Habt ihr einen eigenen Fall eines (bisher) modalen Dialogs, zu dem ihr eine Alternative haben wollt? Dann immer her damit. Bitte möglichst immer nur einen Fall pro Beitrag. Und bitte möglichst einen neuen Fall erst, wenn der laufende abgeschlossen ist.

herbivore

PS: Nachdem nun schon einige Fälle behandelt wurden, prüfe bitte, ob für deinen Fall schon eine passende Alternative genannt wurde und es vielleicht gar nicht nötig ist, ihn (neu) zu posten. Vielen Dank!
private Nachricht | Beiträge des Benutzers
MrSparkle
myCSharp.de - Team

Avatar #avatar-2159.gif


Dabei seit:
Beiträge: 5985
Herkunft: Leipzig

beantworten | zitieren | melden

Hi herbivore,

für die (Windows-)Dialoge zum Öffnen und Speichern von Dateien hab ich für die meisten Anwendungsfälle noch keine brauchbare Alternative gefunden. Dazu verwende ich nach wie vor modale Dialoge. Da es sich allerdings um Dialoge vom Betriebssystem handelt, bin ich mir nicht sicher, ob das mit deiner Frage auch gemeint ist.

Christian
Weeks of programming can save you hours of planning
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo MrSparkle,

ja, die Ausgangslage ist ungünstig. Die eigentliche Lösung, die ich aber leider nicht erzwingen kann, wäre, dass Microsoft eine Möglichkeit anbietet, dass man die Dialoge auch nicht-modal anzeigen kann. Für normale Fenster/Dialoge kann man sich ja auch entscheiden, ob man diese mit Form.ShowDialog modal oder - meiner Meinung nach besser - per Form.Show nicht-modal anzeigt.

Solange es diese Möglichkeit nicht gibt, kann man sich damit behelfen, dass man den Dialog aus einem separaten Thread öffnet. Man muss ein bisschen aufpassen, um keinen Bock zu schießen, aber das ist eine der wenigen Ausnahmen, bei der mehr als ein GUI-Thread angebracht wäre. Es ist zugegeben ein Workaround. Doch einer der gut funktionieren kann, wenn man alles richtig macht. Ich überlege mal, ob ich daraus ein Snippet oder eine Komponente mache.

herbivore
private Nachricht | Beiträge des Benutzers
MrSparkle
myCSharp.de - Team

Avatar #avatar-2159.gif


Dabei seit:
Beiträge: 5985
Herkunft: Leipzig

beantworten | zitieren | melden

Hi herbivore,

den Dialog nicht-modal anzuzeigen, ist sicherlich kein besonders großes Problem. Aber ist das auch sinnvoll? Das würde ja bedeuten, daß der Benutzer nachdem er auf "Datei speichern..." geklickt hat, den Dialog in den Hintergrund bringen, und sein Dokument weiterbearbeiten kann. Wenn er den Dialog wieder in den Vordergrund bringt, ist beispielsweise nicht klar, welcher Stand des Dokuments dann gespeichert wird. Es könnte also dazu führen, daß der Benutzer verwirrt ist, und das sollte man meiner Meinung nach unbedingt verhindern.

Eine bessere Lösung wäre für mich, auf das Öffnen eines zusätzlichen Fensters nach Möglichkeit ganz zu verzichten.

Christian
Weeks of programming can save you hours of planning
private Nachricht | Beiträge des Benutzers
chilic
myCSharp.de - Experte



Dabei seit:
Beiträge: 2136

beantworten | zitieren | melden

Fangts doch einfacher an :-) Einen Speicherndialog halte ich für einen der überzeugendsten um beruhigt modal zu bleiben. Oder eine Sicherheitsabfrage.
-> Bitte *jetzt* eine Entscheidung treffen. Wer doch was anderes tun will bricht das ab und öffnet es später wieder ohne dass Information verloren gehen.
Hier würd ich nicht nur um des Prinzips willen modal vermeiden und dann alles von Hand doch wieder auf modal trimmen.

Es gibt genügend Beispiele die einen schnell ersichtlichen Vorteil bringen. Beispiel Kontoführungsprogramm. Es hat eine Übersichtsliste der Kontobewegungen mit Löschfunktion usw.
Die Eingabe einer neuen Position erfolgte bisher über einen modales Fenster, da im Hauptdialog unübersichtlich.
Währenddessen soll in der Liste nichts geändert werden. Man will sie aber weiterhin readonly bedienen und durchsuchen können um Buchungsnummer / Text / Datum einer ähnlichen Kontobewegung zu suchen. Schließen der Eingabemaske würde evtl. einige Daten wieder verwerfen.

Die Lösung bestand aus dem disablen bestimmter Buttons und Eingriffen in weitere GUI Elemente. Dann kann die Erfassung einer neuen Position nichtmodal erfolgen. Automatisch ging hier nicht viel, es war den Aufwand aber wert. Es muss nur darauf geachtet werden dass das Fenster nicht minimiert wird oder in den Hintergrund gelangt.
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo chilic,

nein, gerade das sehr ich anders. Ich behaupte, es gibt nie einen Grund für einen modalen Dialog. Ich halte es für eine reine Illusion, dass man denkt, dass gerade nur das eine möglich ist und nichts andres. Mein Beispiel mit dem Windows Explorer oben zeigt genau das. Und was die Speicher-Dialoge angeht, habe ich in Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte] ebenfalls aufgezeigt, warum man zu diesem Zeitpunkt noch andere Aktionen durchführen will. Bei einem Abbrechen geht - zumindest bei den Standard-Dialogen - die Information verloren, bis zu welchem Verzeichnis sich der User durchgeklickt hatte. Es geht nicht ums Prinzip, sondern um die konkreten Nachteile, die ich genannt habe. Neben den genannten auch noch, dass man das hinter dem Dialog liegende Fenster nicht verschieben kann, solange der Dialog offen ist.

Natürlich stimme ich dir zu, dass es andere Beispiel gibt, in denen die Nachteile durch die Modalität stärker ins Auge springen.


Hallo MrSparkle,

bei normalen Dialogen kann man einfach den Owner setzen (myDialog.Owner = myForm) und der Dialog bleibt automatisch vor dem Form, kann also gar nicht in den Hintergrund kommen. Das wäre in diesem Fall sicher nicht schlecht. Allerdings würde das wohl bei den (Windows-)Dialogen mit dem Workaround kollidieren, diese in einem separaten Thread zu öffnen. Bei eigenen Dialogen ist es kein Problem.

Ich finde klar, dass das Dokument in dem Stand gespeichert wird, den es hat, wenn man auf "Speichern" drückt. Ich bin nie auf einen anderen Gedanken gekommen. Meine ganze Argumentation in Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte], wo ich explizit auf den Fall eingehen, bei dem man mitten im Auswählen des Speicherpfades merkt, dass man noch eine kleine Änderung im Dokument vornehmen will, basiert genau darauf, dass der aktuelle Stand des Dokuments gespeichert wird.

Wenn wirklich der Stand des Dokuments zum Zeitpunkt des Öffnens des Speichern-Dialogs gespeichert werden soll, kann und sollte dieser Stand angezeigt werden, wenn man dem Dialog wieder aktiviert, er also den Fokus bekommt. Das kann man sicher noch visuell hervorheben, z.B. durch eine sich ändernde Hintergrundfarbe des Dokuments. Jedenfalls sehe ich kein Problem, optisch klar zu machen, was genau passiert.

Es kann in vielen Fällen durchaus sinnvoll sein, wenn man das Öffnen eines separaten Dialogs vermeidet und stattdessen dessen Controls im Hauptfenster anzeigt/einblendet. Bei den Öffnen- und Speichern-Dialogen wird dieses allerdings darauf hinauslaufen, dass man deren Funktionalität nachprogrammieren muss. Das kann man machen.

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



Dabei seit:
Beiträge: 1115

beantworten | zitieren | melden

Modale Dialog, sind dann ok, wenn nichts gemacht werden darf, außer die Bedingungen des Dialoges sind erfüllt.

Ich kenne es z.B. von Software die auf Maschinen läuft. So bald eine Wartungsklappe geöffnet, reagiert die Software auf den Sensor und Blockiert mit einem Modalen Dialog alle Eingabemöglichkeiten. Die Maschine wird natürlich auch angehalten.

Nach dem Schließen der Wartungsklappe oder Eingabe eines Entsprechenden Benutzers. (Wartungstechniker der Entsprechend geschult ist und die UI wider Blockieren kann). Danach ist man dann an genau der Stelle wo man war. Beim Wartungstechniker sind es dann meist die Dialog zu Justierung der Mechanik.

MFG
Björn
Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo Palin,

mein Beispiel mit dem Windows Explorer oben zeigt, dass modale Dialoge auch dann nicht nötig, sind wenn zum Erreichen einer erforderlichen Bedingung die Komplettierung des Dialogs nötig ist. Und es zeigt, dass es es so gut wie immer andere sinnvolle Aktionen gibt, die man nur nicht gleich im Blick hatte, die statt der Komplettierung des Dialogs durchgeführt werden können. Das ist gerade mein Credo: Modale Dialoge sind nie nötig und immer störend. Es gibt immer bessere Alternativen. Und ich bin bereit das an konkreten Fällen zu zeigen.

Meine Aussagen beziehen sich dabei auf Software. Bei echter Hardware mag das anders sein, das überblicke ich gerade nicht. Wenn echte Hardware durch Software [auf einem Desktop-PC] gesteuert wird, sind jedoch wieder keine modalen Dialoge nötig. Es gibt immer einen anderen, besseren Weg. Auch dann, wenn man in einem ungewöhnlichen Sonderfall tatsächlich alle anderen Aktionen verhindern muss (wobei es selbst dann üblicherweise die Möglichkeit gibt, die laufende Aktion abzubrechen, also doch mindesten eine andere sinnvolle Aktion gibt). Das geht nämlich auf viele Arten. foreach (Control control in form.Controls) {control.Enabled = false; } ist bei weitem nicht die einzige Alternative.

herbivore
private Nachricht | Beiträge des Benutzers
chilic
myCSharp.de - Experte



Dabei seit:
Beiträge: 2136

beantworten | zitieren | melden

Vorschlag.
Der Nutzer will einen Vorgang auslösen, der aber wegen fehlenden Angaben so nicht ausgeführt werden kann. Er muss merken dass das gewünschte nicht passiert.

Info. Ich habe mit Software zu tun die hauptsächlich von not digital natives verwendet wird. Menschen die den Computer als notwendiges Übel sehen und mühsam statt versiert damit arbeiten.
zB der ErrorProvider ist eine echt coole Sache. Allerdings birgt er die Gefahr von Aussagen "ich klicke und nichts passiert. Da steht nur so ein komisches Zeichen". Oder noch schlimmer, man klickt und geht wieder weg, in der Annahme es wird schon alles gut sein. Da ist es fast noch zu wenig dass sich eine Meldung mitten in den Bildschirm knallt, eigentlich müsste sich der Rest noch abdunkeln. Bissig gesagt wollen die gar nicht wissen was sie alles parallel tun können sondern möchten/müssen so geführt werden dass sie wenigstens eine Sache zu Ende schaffen :-)
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16112

beantworten | zitieren | melden

Die Frage war, wo ein modaler Dialog sinnvoll ist. Palin's Beispiel ist nahezu perfekt.
Ob da eine Hardware dran steckt oder nicht; da solltest Du jetzt nicht ausweichen ;-)
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo Abt,

deine Behauptung/Vermutung entbehrt jeder Grundlage. Ich habe konkrete Alternativen genannt. Alle Eingaben kann man z.B. durch das genannte foreach (Control control in form.Controls) {control.Enabled = false; } verhindern. Weitere Alternativen kann ich nennen, wenn er kein abstraktes Beispiel macht, sondern ein konkretes. Wie viele Fester gibt es? Wie sehen die aus? Erst dann kann man sagen, ob es vielleicht sinnvoll wäre, den Wartungsdialog so in das Fenster einzublenden, wie es in [FAQ] Assistenten/Wizards: Mit Windows Forms eine Art Frameset einer Website nachbauen gemacht gezeigt wird (natürlich ohne die Navigationsplane). Ein modaler Dialog ist jedenfalls auch für Wartungsklappen nicht nötig.


Hallo chilic,

natürlich muss der Benutzer merken, dass seine Aktion nicht durchgeführt wurde. Das tut er in deinem Fall - so wie ich ihn verstanden haben - daran, dass sich das Dialog-Fenster nicht schließt. Wenn das nicht reicht, dann kann man die Tatsache auch explizit in das Fenster einblenden, z.B. so wie es in [Snippet] Nicht-modale Abfrage als Alternative für MessageBoxen eingeblendet sind.

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



Dabei seit:
Beiträge: 146

beantworten | zitieren | melden

zu Sperrung einer Software:

Hab ein Programm, wenn bestimmte Daten ankommen müssen einige sichtbare TabPages erstmal gesperrt werden, bis der User eine Aktion tätigt.

In diesem Fall packe ich jeweils ein Panel über die TabPages die zu diesem zeitpunkt sichtbar waren.

In diesen Panels ist jeweils ein Image mit dem vorher eine Art screenshots der Child Controls der TabPage gemacht wurde.
(Nicht ganz so kräftig gezeichnet wie die original Controls damit man erkennt das dieser bereich inaktiv ist)

Der User muss ein Button auf dem Panel betätigen damit dann diese TabPage wieder aktiv wird.

Das Panel packe ich einfach drüber um weitere eingabe controls auf billige art und weiße zu blockieren und ich muss mich auch nicht um eventuelle ContextMenüs kümmern.

So blockiere ich auch nicht sofort das komplette FOrmular.
Dieser Beitrag wurde 1 mal editiert, zum letzten Mal von Spyke am .
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo Spyke,

ich finde diese Lösung etwas um die Ecke, aber es ist auf jeden Fall ein Ansatz. Und darum ging es mir ja in diesem Thread. Zu zeigen, dass man mit etwas Überlegen und gutem Willen ohne modale Dialoge und ihre Nachteile auskommt. Jeder wird sicher eine etwas andere Vorstellung haben, wie eine Alternative am besten zu realisieren ist. In diesem Sinne begrüße ich den Vorschlag.

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



Dabei seit:
Beiträge: 1115

beantworten | zitieren | melden

Das es nicht anders geht habe ich nicht behauptet. Aber es ist recht einfach Implementiert und recht "Robust". Was meines Erachtens bei Sicherheitskritischen Anwendungen ein wichtiger Aspekt.

Du hast natürlich recht deiner Ursprünglichen Fragestellung genügt es nicht. Aber ich denke es ist trotzdem ein Aspekt der in einer Diskussion betrachtet werden sollte.
Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo Palin,

sicher ist Robustheit ein Kriterium. Aber foreach (Control control in form.Controls) {control.Enabled = false; } ist nun z.B. auch nicht weniger robust als ein modaler Dialog.

Klar, manche Alternativen sind aufwändiger zu implementieren. Aus meiner Sicht lohnt sich das, wenn dem entsprechende Vorteile in der Benutzerfreundlichkeit gegenüberstehen.

herbivore
private Nachricht | Beiträge des Benutzers
Abt
myCSharp.de - Team

Avatar #avatar-4119.png


Dabei seit:
Beiträge: 16112

beantworten | zitieren | melden

Zitat von herbivore
deine Behauptung/Vermutung entbehrt jeder Grundlage. Ich habe konkrete Alternativen genannt. Alle Eingaben kann man z.B. durch das genannte foreach (Control control in form.Controls) {control.Enabled = false; } verhindern.
Und ich sage, dass dieses Vorhaben völlig unpraktikabel ist und speziell Enabled eine .NET Sache ist.

Wozu soll ich noch Elemente als Disabled anzeigen, wenn das wichtigste aktuell die Warnmeldung ist?
Wenn zum Beispiel das Schneidgas niedrig wird, also eine Warnung, dann kann das ruhig embedded angezeigt werden, da es die Arbeit nicht einschränkt.

Befinde ich mich aber in einer Touch Umgebung und hab dann eine modales Fenster hab ich doch viel mehr Platz um eine große rote Warnung anzuzeigen, weil es ein kritischer Fall ist.
Es ist groß, ich kann es von weitem sehen, was angezeigt wird. Perfekt für das Vorhaben.
Ein Maschinenbediener hat keine Lust da erst irgendeine Font=12px Statusleiste mit unnötigen Disabled Elementen zu sehen. Aus UI-Kontext-sicht völliger Käse.
- performance is a feature -

Microsoft MVP - @Website - @blog - @AzureStuttgart - github.com/BenjaminAbt
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo Abt,

hier soll es um normale Desktop-Anwendungen gehen. So war mein einleitender Text jedenfalls gemeint. Darauf bezog sich meine Behauptung, dass modale Dialoge unnötig sind. Und darauf bezogen sind meine Aussagen stimmig. Du scheinst über etwas ganz anders zu reden, was am Thema vorbei geht. Sollte ich mich irren und du doch normale Desktop-Anwendungen meinen, bescheib es bitte genauer. Am besten mit GUI-Skizze oder Screenshot.

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



Dabei seit:
Beiträge: 1115

beantworten | zitieren | melden

@herbivore
Mir ist an den Punkt nicht klar, welchen mehr wert, der Benutzer an der Stelle, durch den zusätzlichen Code erhält.
Sollte man mal gelesen haben:

Clean Code Developer
Entwurfsmuster
Anti-Pattern
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo Palin,

zusätzlicher Code ist in vielen Fällen gar nicht nötig. Im einfachsten Fall reicht es Form.ShowDialog durch Form.Show zu ersetzen. Ohne irgendwelche weiteren Änderungen. Oder nur mit minimalen Änderungen z.B. dem vorübergehenden Disablen von Controls. Und selbst das kann man in eine extra Bibliotheks-Methode auslagern(*).

Ansonsten habe ich die wichtigsten allgemeinen Nachteile von modalen Dialogen und einige weitere Nachteile in speziellen Fällen, bereits in Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte] beschrieben (bitte lesen). Welche Nachteil es darüberhinaus in einer konkreten Situation gibt, hängt natürlich von der konkreten Situation ab. Dafür ist dann dieser Thread hier.

herbivore

(*) Hier eine erste Skizze, wie so ein Auslagern aussehen könnte. Das kann man sicher noch verfeinern, z.B. dass man
  • am Ende nur die Controls enabled, die zu Beginn enabled waren und
  • nur die Controls disabled, die wirklich disabled werden müssen (was ich am wichtigsten fände) und
  • ein DialogResult zurückgibt und
  • vermutlich noch einiges mehr.
So oder so ist der ganze zusätzliche Code in einer universell einsetzbaren Klasse gekapselt. An der Aufrufstelle entsteht kein zusätzlicher Aufwand, denn mit der folgenden Klasse ist es möglich, einen Dialog genauso einfach anzuzeigen, wie mit ShowDialog, nur dass das dahinterliegende Fenster zumindest verschiebbar bleibt.

dialog.ShowDialogNonModal (owner);

public static class FormHelper
{
    public static void ShowDialogNonModal (this Form dialog, Form owner)
    {
       owner.EnableControls (false);
       dialog.Owner = owner;
       dialog.FormClosing += DialogFormClosing;
       dialog.Show ();
    }

    public static void EnableControls (this Form form, bool enable)
    {
       foreach (Control control in form.Controls) {
          control.Enabled = enable;
       }
    }

    public static void DialogFormClosing (Object sender, FormClosingEventArgs e)
    {
       ((Form)sender).Owner.EnableControls (true);
    }
}
private Nachricht | Beiträge des Benutzers
Ahrimaan
myCSharp.de - Member



Dabei seit:
Beiträge: 363
Herkunft: Thorn

beantworten | zitieren | melden

Hallo Herbivore,

das beispiel mit den deaktivieren deiner Controls finde ich ok, durch einen Modalen Dialog wird dir diese Arbeit aber abgenommen.

Ich sehe es so: Modale Dialoge benutzen Programme seit Äonen. Dieses Verhalten zu ändnern obliegt uns SW Entwicklern und Architekten. Ob es die Kunden dann annehmen ist eine andere Sache.

Ich sehe nicht die Frage wann Modale Dialoge Sinnvoll sind und ob, sondern wie man die Akzeptanz für andere "Mittel" fördert.

Ich zB kriege immer klare Vorgaben unserers Fachbereiches, darf zwar mitmischen bei Veränderungen der Oberfläche, solche Radikalen änderungen allerdings werden abgewatscht mit dem Spruch : "Wie selbst Windows/Linux machen das doch so"

Herbivore, hast du Software ohne Modale Dialoge im Einsatz und wie kommt das an ?

Grüße
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo Ahrimaan,

in der Skizze geht es doch darum, die Nachteile von modalen Dialogen, minderstens, dass das dahinterliegende Fenster nicht verschoben werden kann, zu verhindern. Außerdem ist das Disablen alle Controls im dahinterliegenden Fenster nicht meine erste Wahl. Die Skizze sollte hauptsächlich zeigen, dass man Alternativen zu modalen Dialogen einfach und ohne viel Aufwand als universelle Komponenten kapseln kann. Meine These ist, dass trotz des geöffneten Dialogs oft sinnvolle Interaktionen mit dem Fenster möglich sind, weshalb ich andere Alternativen bevorzuge. Ich gehe halt immer auf die gerade gestellte Frage ein.

Weil es modale Dialoge schon solange gibt, ist es vielleicht - rein mental, nicht wegen tatsächlicher Hindernisse - auch so schwer, davon wegzukommen. :-) Es ist halt schwer, aus eingefahrenen Bahnen herauszukommen.

Ein Versuch, die Akzeptanz für Alternativen zu fördern, ist dieser Thread. Doch dazu muss man natürlich auch an einigen Stellen über Sinn und Unsinn und über Vor- und Nachteile zu sprechen.

Ich verwende modale Dialoge seit langem nicht mehr und hatte nie irgendwelche Problem damit oder dadurch. Auch nicht Kunden oder Benutzern, eher im Gegenteil.


Hallo zusammen,

um selber noch einen Fall zu nennen: Ganz schlimm finde ich, wenn Hilfetexte - vollkommen ohne Not - modal angezeigt werden. Hab ich alles schon erlebt. Gerade wenn in der Hilfe eine Schritt-für-Schritt-Anleitung enthalten ist, der man folgen möchte, ist es natürlich extrem nervig, wenn die Hilfe in einem modalen Dialog angezeigt wird. Hier kann man immer einfach ein normale Fenster statt eines modalen Dialogs verwenden.

herbivore
private Nachricht | Beiträge des Benutzers
inflames2k
myCSharp.de - Experte

Avatar #AARsmmPEUMee0tQa2JoB.png


Dabei seit:
Beiträge: 2358

beantworten | zitieren | melden

Gerade wenn man Spezial-Anwendungen für Unternehmen schreibt ist es oftmals besser Modale Dialoge zu verwenden.

Ein Beispiel aus unserem Haus:
In einer Anwendung können Messwerte für einen Artikel eingegeben werden (Dickenmessungen). Die Messwerte werden gegen die dem Artikeltyp zugeordneten Grenzwerte überprüft.
Derzeit ist es so implementiert, dass bei Über- oder Unterschreitung nur ein Panel eingeblendet wird mit dem Hinweis. Der Benutzer kann also weiter arbeiten und die Werte speichern (Vorgabe vom Kunden, da wirklich mal Artikel außerhalb der Grenzwerte liegen können ist das Speichern dennoch möglich).

Der Kunde fordert nun aber einen Dialog der Bestätigt werden muss, da die Benutzer sonst darauf nicht achten und Fehlmessungen ohne drüber nachzudenken in die Datenbank übertragen werden, was im Nachhinein negative Auswirkungen auf die Auswertung hat. Denn obwohl der Artikel OK war hat der Benutzer sich vertippt und einen völlig unglaubwürdigen Wert in die Datenbank geschrieben.
Dieser Beitrag wurde 2 mal editiert, zum letzten Mal von inflames2k am .
Wissen ist nicht alles. Man muss es auch anwenden können.

PS Fritz!Box API - TR-064 Schnittstelle | PS EventLogManager | Spielkartenbibliothek
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo inflames2k,

es ist ok, wenn der Kunde möchte, dass unplausible Werte explizit bestätigt werden. Doch ein modaler Dialog ist (auch) dafür nicht erforderlich. Hier würde es z.B. reichen, einen Bestätigungs-Button neben den unplausiblen Werten einzublenden. Erst wenn der bzw. alle Bestätigungs-Buttons gedrückt wurden (und dadurch wieder verschwinden), kann der Datensatz als ganzes gespeichert werden.

Das kann man natürlich noch variieren. Wenn z.B. nicht jeder Wert einzeln bestätigt werden soll, sondern nur die Tatsache, dass in dem Datensatz unplausible Werte enthalten sind, kann man auch eine entsprechende Sicherheitsabfrage per [Snippet] Nicht-modale Abfrage als Alternative für MessageBoxen einblenden.

Zusätzlich können unplausible Werte rot dargestellt oder rot hinterlegt oder in anderer Weise hervorgehoben werden, damit sie sofort ins Auge springen. Ich persönlich finde solche optischen Signale sehr hilfreich.


Hallo zusammen,

es ist - ich glaube das zeigt sich langsam - meistens nur eine Frage des Willens, sich auf die Suche nach einer benutzerfreundlichen Lösung zu machen. Ich erhebe nicht den Anspruch, dass ich hier in diesem Thread immer auf Anhieb eine Alternative finde, die dem Geschmack des Entwicklers oder der Benutzer sofort 100%ig trifft. Doch statt sich darauf zu konzentieren, was an meinen Vorschlägen möglicherweise nicht auf Anhieb passt, ist es produktiver, den Ansatz weiterzuspinnen und zu überlegen, wie er weiter verbessert werden, bis er gefällt. Oder eine ganz eigene Alternative zu entwickeln.

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



Dabei seit:
Beiträge: 176

beantworten | zitieren | melden

Ich verstehe ehrlich gesagt die ganze Diskussion nicht wirklich. Was genau soll eigentlich verwerflich sein an modalen Dialogen?

Für mich sind modale Dialoge eine einfache und intuitive Möglichkeit vom Bediener eine Bestätigung, Eingabe, o.Ä. abzufragen, ohne die das Programm nicht weiter arbeiten kann. Klar kann man das auch immer anders lösen, aber warum den Aufwand betreiben, selbst die falsche Ausführung mit eigenem Code zu verriegeln, wenn es dafür ein seit langem bewährtes Standardwerkzeug gibt?
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo Mallett,

verwerflich ist vielleicht das falsche Wort. Positiv ausgedrückt, bin ich der Meinung, dass es immer (deutlich) bessere Alternativen gibt.

Und ich behaupte, dass "... ohne die das Programm nicht weiter arbeiten kann" eine Annahme ist, die bei weitem nicht so oft zutrifft, wie man das denkt.

Ich habe bereits konkrete Gründe genannt, welche Nachteile ich sehe, hier in diesem Thread und zusammengefasst in Warten auf Schließen einer anderen Form [und warum man Dialoge nicht modal machen sollte]. Ich hatte gehofft, dass die verlinkten Threads gelesen werden. :-)

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



Dabei seit:
Beiträge: 520
Herkunft: Münster

beantworten | zitieren | melden

Ich finde, dass gerade Modale Dialoge die Bedienung für nicht so PC-affine Benutzer in vielen Fällen vereinfachen. Viele Benutzer kommen nicht mit mehreren, gleichzeitig geöffneten und gleichzeitig zugänglichen Fenstern klar.


Beispiel:

In der Hauptmaske von Programm A wird eine Untermaske nicht modal aufgerufen. Nachdem der Benutzer die Maske aufgerufen hat, macht er Outlook auf und möchte, nachdem er eine Mail beantwortet hat wieder zurück in sein Programm A wechseln.
Durch die nicht modale Anzeige der Untermaske werden in der Windows Taskleiste Hauptmaske und Untermaske separat angezeigt. D. h. der Benutzer klickt in der Taskleiste auf Programm A und wundert sich, wo seine Untermaske hin ist.

Diese Situation habe ich tatsächlich schon erlebt, woraufhin auf Kundenwunsch der Aufruf der Untermasken auf modal umgestellt wurde.
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo hypersurf,

wenn man im Unterform den Owner auf das Hauptform setzt, dann bleibt das Unterform immer vor dem Hauptform. Ich habs jetzt nicht beim Minimieren ausprobiert, aber selbst wenn es da nicht auf Anhieb (automatisch) klappt, kann man das leicht programmieren.

Eine andere Möglichkeit wäre, den Inhalt des Unterforms in das Hauptform einzublenden. Dann kommt es/er auf jeden Fall wieder mit nach vorne. Je nach Situation kann man den Inhalt des Dialogs zusätzlich zu eigenlichen Inhalt einblenden oder statt des eigentlichen Inhalt (letztes z.B. mit Techniken, wie in [FAQ] Assistenten/Wizards: Mit Windows Forms eine Art Frameset einer Website nachbauen beschrieben).

Ob ein Fenster in der Task-Leiste angezeigt werden soll, kann man zudem einfach über Form.ShowInTaskbar einstellen.


Hallo zusammen,

nochmal: Ich erhebe nicht den Anspruch, auf Anhieb eine Lösung zu nennen, die keinen Raum für Widerspruch zulässt. Manches muss man sicher weiter ausarbeiten und vielleicht noch die eine oder andere Kante abschleifen. Doch wo der Wille ist, genau das zu tun, findet mal meiner Ansicht nach immer Lösungen, die für die jeweilige Benutzergruppe besser geeignet sind, als modale Dialoge.

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



Dabei seit:
Beiträge: 520
Herkunft: Münster

beantworten | zitieren | melden

Zitat von herbivore
wenn man im Unterform den Owner auf das Hauptform setzt, dann bleibt das Unterform immer vor dem Hauptform. Ich habs jetzt nicht beim Minimieren ausprobiert, aber selbst wenn es da nicht auf Anhieb (automatisch) klappt, kann man das leicht programmieren.

Wenn die Untermaske immer vor der Hauptform bleibt ist die Untermaske modal.

Zitat von herbivore
Eine andere Möglichkeit wäre, den Inhalt des Unterforms in das Hauptform einzublenden. Dann kommt es/er auf jeden Fall wieder mit nach vorne. Je nach Situation kann man den Inhalt des Dialogs zusätzlich zu eigenlichen Inhalt einblenden oder statt des eigentlichen Inhalt (letztes z.B. mit Techniken, wie in [FAQ] Assistenten/Wizards: Mit Windows Forms eine Art Frameset einer Website nachbauen beschrieben).

Das ist definitiv eine gute Möglichkeit. Ich persönlich würde am liebsten auf alle Untermasken verzichten und nur mit Tabs arbeiten. Es gibt mittlerweile ja auch TabControls bei denen man einzelne Tabs auf verschiedene Monitore legen kann. So könnte man gänzlich auf Untermasken verzichten.

Zitat von herbivore
Ob ein Fenster in der Task-Leiste angezeigt werden soll, kann man zudem einfach über Form.ShowInTaskbar einstellen.

Jep, das hatten wir in dem von mir beschriebenen Fall aber extra nicht deaktiviert, weil es ja auch versierte Benutzer gibt die mit vielen gleichzeitig geöffneten Fenstern gut klar kommen und diese effektiv nutzen (z. B. auf mehreren Monitoren). Dann kam der Chef des Kunden, welcher nicht mit so vielen Fenstern klar kam und alles wurde modal X(
private Nachricht | Beiträge des Benutzers
Ezio
myCSharp.de - Member

Avatar #avatar-3575.png


Dabei seit:
Beiträge: 196

beantworten | zitieren | melden

Hallo zusammen,

ich gebe mal meine bescheiden Meinung dazu:
Je länger ich das Thema mitlese und darüber nachdenke, desto mehr kristallisiert sich für mich heraus, dass sobald die Software ein abgeschlossenes System ist herbivores These richtig ist.
Ich finde es ist wesentlich schöner und benutzerfreundlicher Fehlerstellen zu markieren und abhängige Funktionen zu deaktivieren, solange der Fehler nicht behoben ist. Oder anders: Was soll das ein Fenster aufpoppen zu lassen, in dem man eine Aktion fordert und erst danach an einer anderen Stelle weitergearbeitet werden kann? Was ist, wenn man den Wert erst irgendwo erfragen muss? Dann ist das Programm solange nicht nutzbar, bis man dem 1000.en nachtelefoniert hat! 8o

Ich behaupte, wenn man herbivores These widerlegen will, muss man in die Richtung voneinander abhängiger Programme oder Maschinensteuerungen denken, wo man "von außen" Fehlerzustände bekommt.
Also so die Richtung von Palin: Was ist, wenn ein physisch sicherheitskritischer Zustand auftritt? Darf dann etwas an der Software eingestellt werden, solange der Zustand, der zwangsläufig einen Prozess-Stopp bedeutet, nicht behoben ist? Oder würde dies zu Inkonsistenzen führen? Dann könnte man wahrscheinlich aber die Gegenfrage aufstellen: Ist in diesem Fall die Software gut designed?

Soweit von mir.

Ezio
private Nachricht | Beiträge des Benutzers
herbivore
myCSharp.de - Experte

Avatar #avatar-2627.gif


Dabei seit:
Beiträge: 52329
Herkunft: Berlin

Themenstarter:

beantworten | zitieren | melden

Hallo Ezio,

danke für die Einschätzung. Diese hat was für sich.


Hallo hypersurf,
Zitat
Wenn die Untermaske immer vor der Hauptform bleibt ist die Untermaske modal.
nein, das Davorbleiben wird durch die Owner-Beziehung verursacht. Man kann es also durch Setzen der Owner-Beziehung erreichen, unabhängig davon, ob der Dialog modal ist oder eben nicht. Andersherum stimmt es. Wenn der Dialog modal ist (im hier diskutieren Sinne), dann bleibt er auch immer vor dem Hauptform.
Zitat
Dann kam der Chef des Kunden, welcher nicht mit so vielen Fenstern klar kam und alles wurde modal
Das ist natürlich tragisch. Wenn man gute Alternativen anbieten kann, kann man sowas mit etwas Glück verhindern.

herbivore
private Nachricht | Beiträge des Benutzers