Formulardaten auslesen

[linus]

Ich benutze für klassische Eingabe-Dialoge i.d.Regel eine andere Vorgehensweise und zwar folgende:

- die Formular-Instanz bleibt immer "am Leben", d.h. die Formular-Instanz wird über die Formular-Verwaltung automatisch erstellt und beim Programme-Ende automatisch freigegeben (muss man nix denken )
- jedes Formular kriegt eine Methode, die bei mir immer TFormular.Execute() heißt.
- dieser Methode wird eine Objekt-Instanz übergeben (Objekt-Klassen sind in einer zentralen Unit deklariert), mit der das Formular die notwendigen Arbeiten verrichten soll
- in dieser .Execute()-Methode werden nacheinander folgende Schritte ausgeführt:
-> Controls en-/disablen
-> die Daten aus der übergebenen Objekt-Instanz in die Controls laden (Edit-Felder, Listen, etc. befüllen)
-> ShowModal aufrufen und auf dessen Rückgabewert prüfen: bei mrCancel einfach weg, bei mrOK die Daten aus den Controls zurück in die Objekt-Instanz laden (ModalResult := mrCancel wird bei Click auf Abbrechen-Schalter gesetzt; ModalResult := mrOK wird bei Click auf OK-Schalter gesetzt, nachdem vorher die Plausi-Prüfungen durchgelaufen sind)

Kann man natürlich auch alles anders lösen, für mich ist es "schön und sinnvoll", dass die notwendigen Arbeiten (Anzeigen, Prüfen, zurückladen der Daten) innerhalb des Formulars stattfinden und nach erfolgter Bearbeitung in einer geschlossenen Objekt-Struktur zur weiteren Verarbeitung fix und fertig zur Verfügung stehen.

[Mathias]

Naja, modale Formulare sind meines Erachtens ohnedies nur für "quick and dirty" Programme geeignet, viel bedienerunfreundlicher geht es wohl nicht.

Es kommt immer auf die Verwendung an, ob man Show oder Showmodal nimmt.

[braunbär]

Bedienerfreundlich ist showmodal nie, egal, welche Verwendung. Wenn es nur um die Frage Abbrechen/weitermachen oder sonst ein ja/nein geht, kann man es sehr zur Not gerade noch vertreten.
Für den Programmierer ist es etwas bequemer, aber das ist eigentlich keine Rechtfertigung dafür, den User zu piesacken.
Während ein modales Fenster offen ist, kann man nicht einmal die Position des aufrufenden Formulars verändern.

[Mathias]

Während ein modales Fenster offen ist, kann man nicht einmal die Position des aufrufenden Formulars verändern.

Eine typische Windows-Krankheit, dies hat mich auch schon viel genervt.
Unter Linux kann man die Fenster verschieben, wie wen nicht währe.

Bedienerfreundlich ist showmodal nie, egal, welche Verwendung. Wenn es nur um die Frage Abbrechen/weitermachen oder sonst ein ja/nein geht, kann man es sehr zur Not gerade noch vertreten.

Wieso zur Not ?
Wie willst zB. beim Beenden einer Anwendung das berühmte "wollen sie noch speichern ?" lösen ?

[gladio]

Bedienerfreundlich ist showmodal nie, egal, welche Verwendung. Wenn es nur um die Frage Abbrechen/weitermachen oder sonst ein ja/nein geht, kann man es sehr zur Not gerade noch vertreten.
Für den Programmierer ist es etwas bequemer, aber das ist eigentlich keine Rechtfertigung dafür, den User zu piesacken.

Genau das liebe ich an ShowModa ..len Fenstern: Der Nutzer wird vernünftig geführt und kann keinen Unsinn anstellen, z.B. das fenster einfach in den Hintergrund schieben.
Es gin ja um Dateneingaben und nicht ums Malen oder Texten oder so.
Wir programmieren ja für Nutzer und man sollta da immer davon ausgehen, daß sie im Zweifel nicht das tun, was sie sollen.

[linus]

Ich persönlich bin ein Freund von modalen Fenstern - und zwar nicht nur als Programmierer, sondern auch als User, weil sie i.d.R. eine klare Anwenderführung erlauben.

Nicht-Modale Fenster sind meines Erachtens da sinnvoll, wo die Eingaben des Nutzers direkt verarbeitet werden müssen, das kann z.B. bei grafischen Anwendungen sehr praktisch sein. Dagegen sind modale Fenster überall dort angebracht, wo der Nutzer eine Reihe von Eingaben macht, die als Gesamtheit sinnvoll sein müssen.

Beispiel: In einer Anwendung werden für eine Berechnungsroutine eine Reihe von Parametern benötigt. Bevor diese tatsächlich in die Berechnung einfließen können, muss geprüft werden, ob der Parametersatz stimmig ist oder ob unsinnige Werte eingegeben wurden. Erst wenn das geprüft wurde kann die Software sinnvoll weiterarbeiten.

Fazit: Es gibt kein besser oder schlechter, man muss sich einfach überlegen, wo ist was sinnvoll und wo nicht.

[braunbär]

sondern auch als User, weil sie i.d.R. eine klare Anwenderführung erlauben.

Genau das liebe ich an ShowModa ..len Fenstern: Der Nutzer wird vernünftig geführt und kann keinen Unsinn anstellen, z.B. das fenster einfach in den Hintergrund schieben.

Wenn ihr euch gerne von eurem Computer bevormunden lasst - dagegen lässt sich schwer argumentieren. Wenn ich ein Fenster in den Hintergrund schieben will, dann mache ich das nicht aus reiner Blödheit, sondern weil ich mir irgend etwas dabei denke. Ziemlich sicher etwas, woran der Programmierer nicht gedacht hat. Ich brauche keine "vernünftige FÜHRUNG", jedenfalls keine, deren Zwang ich mich unterwerfen muss, vielen Dank! Was ich brauche, ist eine vernünftige, übersichtliche Bedieneroberfläche, mit deren Hilfe ich genau das machen kann, was ich gerade machen will.

Modale Fenster "erlauben" übrigens kein klare Anwenderführung, sondern sie zwingen dem Anwender die "Führung", die sich der Programmierer ausgedacht hat, auf. Das ist ein kleiner, aber feiner Unterschied.

und kann keinen Unsinn anstellen, z.B. das fenster einfach in den Hintergrund schieben.

Warum sollte es ein "Unsinn" sein, ein Fenster in den Hintergrund zu schieben, wenn man auf die Schnelle anderes machen will (im gleichen Programm). Das ist, von den allerprimitivsten Anwendungen abgesehen, ein völlig normaler Vorgang.

Wie willst zB. beim Beenden einer Anwendung das berühmte "wollen sie noch speichern ?" lösen ?

Das ist so ziemlich der einzige Anwendungsfall, in dem nichts gegen ein modales Fenster spricht. An der Stelle eine neue Aufgabe im Programm zu starten, wäre keine gute Idee, weil der User mitten in diesem neuen Task auf das Beenden-Fenster zurückkommen könnte und dann mit dem Beenden des Programms der andere, frisch begonnene Task abgewürgt würde.

Fazit: Es gibt kein besser oder schlechter, man muss sich einfach überlegen, wo ist was sinnvoll und wo nicht.

Modale Fenster sind praktisch immer schlechter, weil sie den Benutzer unnötig einschränken (von den einfachsten Single-Form Anwendungen abgesehen). Es sei denn, man hat als Anwender totale Vollkoffer, die mit Garantie jeden denkbaren Blödsinn machen. Wir hatten einen Kunden mit solchen Mitarbeitern, für den haben wir auf seinen Wunsch hin extra alle Programmfeatures unseres Frameworks, die dem User mehr Flexibilität geben, in seinem Programm deaktiviert. Aber so etwas sehe ich eher als extrem seltene Ausnahme.

[and4more]

@Braunbär: Also ob modale Fenster "Blödsinn" sind möchte ich mal dahingestellt sein lassen, denn manchmal benötigt ein Programm ja bestimmte Daten ohne die ein sinnvolles (Weiter-)Arbeiten nicht möglich ist.
Eine andere Alternative zur dieser Form der "strikten" Benutzerführung könnten aber auch Menüpunkte/Buttons o. a. sein, die solange versteckt werden bis alles eingegeben ist, was zum sinnvollen weiterarbeiten nötig ist, das wäre dann nicht so "brutal", kann aber zur Verwirrung beim (ungeschulten) Nutzer führen.
@dummy: Zum Fensterhandling gibt's ja die Möglichkeit die Inhalte in Variablen zu speichern, bevor das modale Fenster geschlossen wird (es gibt auch noch 'NilandFree', dann lässt sich auch die Klasse wieder sauber instantiieren). Spart natürlich Speicher, dafür geringfügig schlechteres Laufzeitverhalten, da die Klasse beim erneuten Aufruf erst wieder instantiiert werden muss.
Wenn genug Speicher da ist und sowieso mehrmalige Zugriffe auf das Fenster erfolgen sollen würde ich 'Hide' bevorzugen und bei 'Show' alle Felder löschen, so lassen sich die Variablen weiterverarbeiten, während das Fenster "geschlossen" ist.

[braunbär]

Nimm als Beispiel ein einfaches Fakturierungsprogramm mit Kunden- und Artikelkartei.
Du bist gerade dabei, eine Rechnung zu schreiben, und füllst ein modales Formular mit irgendwelchen Artikeldaten aus. Jetzt ruft ein Kunde an und möchte wissen, ob Artikel A567 lagernd ist, oder wie lange die Lieferzeit ist. Mit einem modalen Formular kannst du nur entweder den Vorgang, an dem du arbeitest, abbrechen (und danach alles bisher eingegeben neu eingeben) oder dem Anrufer bedauernd mitteilen, dass du ihm leider gerade keine Auskunft geben kannst, weil der Computer ... eh schon wissen. Das modale Formular blockiert dir nämlich das ganze Programm.
Ist das Eingabeformular nicht modal, dann suchst du einfach den Artikel heraus (via Hauptmenu-Eintrag zur Artikelverwaltung), gibst dem Kunden die gewünschte Auskunft und machst dann mit deiner Arbeit weiter.

Manchmal braucht man auch zum Ausfüllen eines derartigen Formulars Daten, die irgendwo anders im Programm abrufbar sind. Ist das Formular modal, dann hast du da keine Chance. Ich arbeite sehr viel mit einem Börsenhandelsprogramm, in dem fast alle Eingaben über modale Formulare erfolgen. Und täglich überkommt mich sicher ein Dutzend mal der Wunsch, die Programmierer, die dieses Programm verbrochen haben, in eine Ein-Weg-Rakete zum Mond zu verfrachten.

[and4more]

...ja genau das ist der Punkt. Man sollte sein Programm nach der Erfordernis dessen ausrichten was es leisten soll und das natürlich unter dem Aspekt der bestmöglichen “Usability“, was aber keineswegs bedeutet, dass ein modales Fenster zwingend schlecht sein muss. Es richtet sich eben nach den spezifischen Erfordernissen der Anwendung. Daher finde ich eine allgemeine Verurteilung modaler Fenster ohne genaue Kenntnis der Anforderungen etwas voreilig. Ich gehe gerne davon aus, dass derjenige der eine Anwendung programmiert sich auch Gedanken über das Design macht. Zum Beispiel ist ja vorstellbar, dass bei einer Datenbankbearbeitung das Programm einen Vorschlag zur Übernahme bereits vorhandener (Teil-)Datensätze macht. Da macht es dann natürlich keinen Sinn wenn der User zwischenzeitlich die Gelegenheit erhält bereits eingegebene Daten nochmal zu ändern.

[braunbär]

Natürlich macht sogar das Sinn. Wenn mir das Programm Daten vorschlägt, die offensichtlich falsch sind, dann will ich vielleicht gleich nachschauen, was da los ist, wo es diese Daten her nimmt, und das eventuell dort korrigieren, bevor ich die im Formular vorgeschlagenen Daten ebenfalls richtig stelle und die Eingabe fortsetze. Ein modales Formular muss ich dazu erst schließen und nachher neu aufrufen.

Aber hauptsächlich geht es darum, dass man bei nicht modalen Formularen jederzeit eine völlig andere Arbeit einschieben kann, ohne das gerade offene Formular erst mit "abbrechen" schließen zu müssen. Und das hängt nicht von den "spezifischen Erfordernissen der Anwendung" ab, sondern es betrifft jedes Programm, das über die simpelste 2-Fenter-Anwendung hinausgeht. Deshalb ist das Konzept des modalen Fensters meines Erachtens ein schlechtes Design, das man vermeiden sollte, wo immer es möglich ist. Es braucht dann eben etwas mehr Programmieraufwand und ein gescheites Konzept, um trotzdem sicherzustellen, dass der aktuelle "Programmstrang" so lange pausiert, bis die nötigen Daten zur Verfügung stehen, d.h. bis der User das entsprechende Eingabefenster geschlossen hat.