Laden...

Vorüberlegung zur Form2Form-Kommunikation: Programm-Design überdenken

Erstellt von ErfinderDesRades vor 16 Jahren Letzter Beitrag vor 15 Jahren 13.621 Views
Information von herbivore vor 16 Jahren

Dies ist ein Thread, auf den aus der FAQ ([FAQ] Kommunikation von 2 Forms) verwiesen wird. Bitte keine weitere Diskussion, sondern nur wichtige Ergänzungen und diese bitte knapp und präzise. Vielen Dank!

ErfinderDesRades Themenstarter:in
5.299 Beiträge seit 2008
vor 16 Jahren
Vorüberlegung zur Form2Form-Kommunikation: Programm-Design überdenken

Die erste Überlegung sollte m.E. sein: Brauche ich wirklich ein GUI mit mehreren unabhängigen Forms?
Tatsächlich gibt es kaum professionelle Anwendungen, die auf mehrere Forms angewiesen sind.
Um genau zu sein: Ich kenne das nur von Messenger-Programmen, und da finde ich es recht unpraktisch, bei Bedarf das jeweils andere Form in der Taskleiste suchen zu müssen.

**Wozu könnte man ein Form2Form-Design brauchen?***Navigation in einem Form, Arbeitsfläche auf dem anderen? - da bietet sich eigentlich der SplitContainer geradezu an. *Eingabe auf dem einen Form, Ergebnis-Ansicht auf dem anderen? - Für den User klarer strukturiert wäre ein TabControl mit den 2 Reitern "Eingabe" und "Ergebnis" *Arbeitsfläche auf dem einen, Administration auf dem anderen (mein Messenger ist so gestrickt)? - ebenfalls evtl. besser auf einem TabControl.

Es muß nicht ein Tabcontrol sein, auch UserControls, mit .Show() quasi zuschaltbar, sind denkbar, oder FlyOut-Panels oder dergleichen.

Von diesem "echten" (und fragwürdigen) Form2Form-Design zu unterscheiden sind modale Dialoge: Passwort-Eingabe, Datei-Suche, Farb-Auswahl, Druck-Vorschau, sowas.
Hier ist die Kommunikation super einfach, schön prozedural - HauptForm startet den Dialog, und wertet die Eingaben aus, nachdem er geschlossen wurde.
Auch modale Dialoge können sehr unfreundlich sein - viele Datenbänker lieben es ja, für jeden Eintrag ein Extra Form aufpoppen zu lassen, und dann "Übernehmen" und "Schließen" klicksen zu müssen, statt eine übersichtliche Ansicht zu gestalten, in die man die erforderlichen Werte einfach eintragen kann.

Ich hab eine mehr oder weniger kleine Beispiel-Anwendung gebastelt (mehr: Designer-Code, weniger: User-Code).
Mit Passwort-Dialog (modaler Dialog), und dann eine Art Warenkorb auf einem TabControl (also Eingabe-Ergebnis-Muster).
Die Kommunikation mit dem Passwort-Dialog ist abgehandelt in folgenden Zeilen:


      private void frmMain_Load(object sender, EventArgs e) {
         string KundeID;
         while (true) {
            using (PasswortForm Frm = new PasswortForm()) {
               if (Frm.ShowDialog(this) != DialogResult.OK) {
                  this.Close();
                  return;
               }
               KundeID = Frm.Password;
            }
            if (KundeTableAdapter.ValidateKundeID(KundeID).Value > 0) break;
            MessageBox.Show(this, "Falsch!");
         }
         //hier gehts dann wirklich los

Und auf dem PasswortForm die Property Password:


      public string Password {
         get { return this.textBox1.Text; }
      }

Also wahrhaftig anderes als die sog. "rocket science".

Zur eigentlichen Form2Form-Kommunikation gibt das Sample codemäßig nicht viel her, da sie sich erübrigt hat.
Die Laufzeit kann vllt. illustrieren, wie eine recht anspruchsvolle und (hoffentlich) ergonomische Funktionalität auf einem Form untergebracht sein kann.

Der frühe Apfel fängt den Wurm.

F
10.010 Beiträge seit 2004
vor 16 Jahren

Witzig, das immer solche Sprüche kommen :

Auch modale Dialoge können sehr unfreundlich sein - viele Datenbänker lieben es ja, für jeden Eintrag ein Extra Form aufpoppen zu lassen, und dann "Übernehmen" und "Schließen" klicksen zu müssen, statt eine übersichtliche Ansicht zu gestalten, in die man die erforderlichen Werte einfach eintragen kann.

Diesen Kommentar kannst Du nur machen, wenn Dir nicht ständig Endbenutzer
Daten verändern, weil sie nicht bedacht haben, das das alles freigeschaltet ist.

Für SW die nur du selber benutzt ist das noch OK, aber sobald da ein anderer
vor sitzt, wirst du schon sehen was Du davon hast.

In 95% aller Fälle ist die von Dir kritisierte Vorgehensweise die Bessere.

Und sorry, aber grössere Anwendungen ( deine ist ja nun wirklich nicht gross oder complex )
so zu verfassen ist nicht nur fehleranfällig, es ist auch schlecht zu warten.
Schon mal was von MVP/MVC, IOC und Co gehört?

Schau dir dann lieber etwas wie XAF oder CAB an, da siehst Du wie es wirklich gemacht wird.

Alles in allem ist dein Vorschlag OK wenn man so ein bischen an funktionen hat,
aber dann hört es auch schon auf.

ErfinderDesRades Themenstarter:in
5.299 Beiträge seit 2008
vor 16 Jahren

Ja, das war wohl richtig ungeschickt von mir, mein Statement zu modalen Dialogen so provokant zu formulieren.
Geschieht mir geradezu recht, dassich dafür so runtergemacht werde.
Aber inhaltlich kannich da eigentlich nicht von abgehen, m.E. sind modale Dialoge eher was für seltenere Eingaben, und wenn man sich ein bisserl'n Kopf macht, finden sich für häufigere Eingaben bestimmt ergonomischere Lösungen (die ebenso sicher sind).

Und MVP, MVC, IOC, XAF und CAB sind hier ja gar nicht Thema, auch die modalen Dialoge sind eher Randthema. Mir geht es v.a. darum, zur FAQ "Kommunikation zwischen unmodal angezeigten Forms" den Gesichtspunkt beizutragen, daß man die evtl. überflüssig machen kann, durch ein geeignetes Ein-Form-GUI, u.U. sogar mit einem Gewinn an Benutzerfreundlichkeit.

Der frühe Apfel fängt den Wurm.

F
10.010 Beiträge seit 2004
vor 16 Jahren

Wie gesagt, dein Gewinn an "benutzerfreundlichkeit" erkaufst Du dir aber dann mit
dem Problem, das ständig Daten unbeabsichtigt geändert werden.

Und deshalb meine Aussage, für dich ist es OK, bei Kunden niemals, egal wie die auch betteln.

Und man muss dies auch nicht Modal machen, aber eben niemals in den Listen.

2.760 Beiträge seit 2006
vor 15 Jahren

Brauche ich wirklich ein GUI mit mehreren unabhängigen Forms?
Tatsächlich gibt es kaum professionelle Anwendungen, die auf mehrere Forms angewiesen sind.

Bei mehreren Monitoren schreit es meistens gerade zu nach einem SDI-Konzept. (Ja, ich trauer der Delphi1-7 IDE hinterher)