Verwaltung aller Forms eines Programms

[mkinzler]

Zitat:

Wird eine solche Liste nicht bereits in Screen.Forms gepflegt?

Jein.

man würde so trotzdem zumindest eine globale Variable benötigen.

[Uwe Raabe]

Zitat von mkinzler:

man würde so trotzdem zumindest eine globale Variable benötigen.

Wieso? Was sollte diese Variable denn enthalten?

[DieDolly]

Das wird ein schönes Thema. Bin schon gespannt, wie der Grundcode / die Grundversion so eines Form-Managers aussehen könnte.

[Sinspin]

Zitat von DieDolly:

Das wird ein schönes Thema. Bin schon gespannt, wie der Grundcode / die Grundversion so eines Form-Managers aussehen könnte.

Wahrlich! Zumal wir hier mit dem Threadstarter einen Neuzugang und dessen ersten, und bisher einzigen, Post haben.
Trotzdem wurden hier schon interessante Lösungen gepostet.

[venice2]

Zitat von Uwe Raabe:

Zitat von mkinzler:

man würde so trotzdem zumindest eine globale Variable benötigen.

Wieso? Was sollte diese Variable denn enthalten?

Forms? LOL

Was für ein Monster Projekt. Denke da ist einiges im argen das man mehr als 1500 Formulare benötigt..
Mein Ratschlag schreibe es neu.

[TurboMagic]

Zitat von venice2:

Zitat von Uwe Raabe:

Zitat von mkinzler:

man würde so trotzdem zumindest eine globale Variable benötigen.

Wieso? Was sollte diese Variable denn enthalten?

Forms? LOL

Was für ein Monster Projekt. Denke da ist einiges im argen das man mehr als 1500 Formulare benötigt..
Mein Ratschlag schreibe es neu.

Neu schreiben bei 1500 Forms?
Wer zahlt den sowas?

Ob 1500 Forms viel sind kommt halt auf die Art des Projektes an...

[IBExpert]

Vor ca 15 Jahren hatte ich mal für einen Kunden basierend auf seiner Firebird Datenbank Struktur
ein Quellcodegenerator geschrieben, der so ein ähnliches Projekt mit ca 800 Formularen
automatisch erzeugt hat (es gab auch auf der Ekon damals Sessions zu dem Thema von mir).

Idee war das es zu jeder der 800 Tabellen Tabelle eine pas und eine dfm Datei erzeugt werdent,
diese automatisch mit allen Feldern Grids, Edit Controls o.ä. nach einer zentralen Routine
zusammengestellt wurden.

Außerdem wurde dann automatisch zu jedem automatisch erstellten Form ein vererbtes Formular
erzeugt wurde, in dem man dann für die komplexeren Masken seine eigenen Ergänzungen und
Anpassungen machen konnte, ohne das die beim nächsten Durchlauf des Quelltextgenerators
gleich wieder übergebügelt werden.

Alle Formulare wurden dann zur Stammdatenbearbeitung in TMenu* eingetragen und man hatte mit relativ
wenig Aufwand für eine sehr komplexe Datenbank schon mal ein voll funktionsfähiges Grundgerüst, um
sämtliche Daten in der GUI bearbeiten zu können und trotzdem nicht bei jeder Datenbankänderung
hunderte Formulare einzeln anpassen zu müssen ....

Ergebnis war bei 800 Tabellen aber dann ein dpr Projekt mit ca 3200 Dateien (je 2 dfms und 2 pas pro
Tabelle), was über den Quelltextgenerator relativ einfach zu handlen war und wir konnten uns auf
die komplexen Formulare konzentrieren. Außerdem natürlich noch ein paar weitere Units für die
Basistechnik.

Grund für die Architektur waren in dem Kundenprojekt (weltweit tätiges Unternehmen mit ca
2000 Mitarbeiter), das die daraus entstehende Kunden/Auftrags/Produkt Verwaltung in
Teilbereichen sehr komplex waren und 2 Mitarbeiter nur damit beschäftigt waren, das
Datenmodell anhand von Grundregeln an das anzupassen, was die Fachabteilung in dem
jeweiligen Bereich vorgegeben hat. Beide hatten nicht eine einzige Pascal/Delphi Quellcode
jemals gesehen, konnten aber wenn sie die angeforderten Strukturen der Fachabteilung
verstanden hatten, mit simplen create table befehlen die Strukturen in der Datenbank
anlegen und dann on demand oder im Nachtdurchlauf dann eh eine neue exe mit der Fachabteilung
antesten und deren Feedback zeitnah auf das Datenmodell anpassen oder komplexe wünsche
an die Delphi Entwickler weitergeben, die sich dann mit den Anforderungen im vererbten Formular
auseinander setzen konnten. Das war ausgesprochen effektiv, weil nicht ein Fachmann aus der
Fachabteilung mit dem erforderlichen Prozesswissen einen Programmierer, der von den Prozessen
keine Ahnung hat und oft auch nicht wirklich in der Kommunikation den Fachleuten gewachsen ist
und andauernd "Ja, hab ich verstanden" sagt, obwohl er keine Ahnung hat, wovon der andere redet.
Die "Middleware" Abteilung zwischen Anwendern und Programmierern hat ganz sicher sehr viel
Zeit gespart.

Wenn man aber das fertige Projekt sieht und klassische Delphi Programmierung gewöhnt ist
bei der man jede zeile code selber geschrieben hat und jedes Form selber erzeugt hat, und den
Quelltextgenerator nicht kennt und auch nicht selber anpassen kann, wird man
mit diesem Projekt komplett überfordert sein und sich höchstens wundern, warum alle
objektnamen, quelltextformatierungen immer so einheitlich aussehen.

Unsere aktuelle brp Architektur geht dabei noch einen Schritt weiter und erzeugt alles, was damals
in dfm/pas dateien ging, automatisch zur Laufzeit und daher kann eine exe völlig unterschiedliche
DBs bedienen, weil ähnlich wie beim browser/webserver bei uns die exe alle informationen aus der
Firebird db zieht und dort auch alle Prozessfunktionen mit Bezug zu Tabellen als SP abgelegt sind.


Fazit: Anzahl der Forms ist nicht generell ein Problem, wenn es aber (wie ich das extrem oft
bei Kunden gesehen hab) jedes mal individuell erzeugte Formulare sind, und Datenmodule im Projekt
sind, bei der die Komponenten darauf selbst den Platz auf einem 4k Monitor sprengen, dann zitiere
ich mal einen Kollegen von früher (Carlos Ebers, leider auch in diesem Sommer gestorben) auf die
Frage

"Was würdest du mit dem Projekt machen"
Seine Antwort: fdisk

(für nicht ganz so alte Hasen: das ist der dos befehl gewesen, um die partition zu löschen und neu
zu erstellen)

[TiGü]

Vielleicht sollte man erstmal die Motivation klären, also die Frage nach dem Warum?
Ein so großes und über die Jahre gewachsenes Projekt stellt man ja nicht aus Spaß um.
Sowas bezahlt ja kein Kunde bzw. es hat kein konkreten Kundennutzen.

@hgf: Was ist deine Hauptmotivation? Was willst du konkret erreichen? Was soll verbessert werden?
Ich könnte mir vorstellen, das dein Hauptanliegen ist, dass beim Programmstart in der DPR nicht immer alle Formulare erzeugt werden.

Das entwickeln eines Form-Managers und das anmelden/registrieren der Formulare darin kann ich mir ja noch relativ simpel vorstellen.
Schwieriger wird es dann, den restlichen Quelltext daran anzupassen. Auch aufgrund der Menge der zu bearbeitenden Units.
Ohne vernünftige automatisierte Verarbeitung durch geschicktes Suchen & Ersetzen/RegEx/Grep/WasAuchImmer wird es zu zeitaufwendig.
Ein bisschen hakelig wird es dann bei dem von dir angesprochenen umändern der Formvariablen zu Funktionen, die aus einem Container (im Form-Manager), dir die richtige Instanz erzeugt und zurück liefert.
Hier kommt das von Redeemer angesprochene Problem mit dem Identifikator zum tragen.
In einer ersten Iteration würde ich vorschlagen, nicht den Formularnamen zu wählen, sondern den Classtype als Schlüssel für ein TObjectDictionary zu verwenden.

[Sinspin]

Hallo, die Formulare werden beim Programmstart alle geladen? Das wird dann aber ein weilchen dauern?

Ich habe nur rund 100 Formulare. Die können sich gegenseitig aufrufen oder Daten senden. Dabei ist egal ob sie schon geladen sind oder nicht.
Jede Form hat einen eindeutigen Klassennamen oder einen registrierten class alias. Function RegisterClassAlias, hat jede Form unit im initialization.
Zur Laufzeit wird als erstes im Formmanager geschaut ob der Klassenname schon da ist und die Form schon offen. Ansonsten wird ein Object der Klasse erstellt und eingetragen.
Damit lassen sich die kompletten Sessions speichern und wieder herstellen. (simple gesagt. Da gehört schon noch ein bisschen mehr dazu).
Alle meine Forms haben eine gemeinsame Basisklasse die sich um die meißten Dinge gemeinsam mit dem Formmanger kümmert.

[EmWieMichael]

Hallo hgf,

ich arbeite aktuell an einer Neuprogrammierung einer Anwendung, bei der bisher quasi alle Fenster im modalen Modus geöffnet werden. Jetzt soll der Anwender die Möglichkeit haben, einzelne Arbeitsbereiche auch mehrfach öffnen zu können.
Ich registriere die Fenster (TForm) in einer eigenen Liste, die aktuell so aussieht:

Delphi-Quellcode:

  TWindowListData = Record
    WinTyp               : Integer;
    WinId                : Integer;
    WinObject            : TObject;
    MessageHandle        : HWND;
    TheMessage           : Word;
  end;

  PWindowListItem = ^TWindowListItem;
  TWindowListItem = Record
    Data                 : TWindowListData;
    Prev                 : PWindowListItem;
    Next                 : PWindowListItem;
  end;

Das Anlegen und Anzeigen eines Fensters erledigt eine globale Funktion. Owner eines jeden Fensters ist das Hauptformular. Soll ein Fenster geschlossen werden (durch Anwender) sendet das betreffende Fenster eine für den Fenstertyp individuelle Nachricht mit der Id des Fensters an das Hauptformular (z.B. WM_RELEASE_PERSFORM). Anhand der Id wird der entsprechende Record aus der Liste geholt und das Fenster gelöscht. Die Attribute MessageHandle und TheMessage dienen hier für eine optionale Nachricht, die an ein bestimmtes Fenster gerichtet werden soll, wenn das Fenster geschlossen wird (z. B. an ein aufrufendes Fenster).
Die o. g. individuelle Nachricht ist nicht unbedingt notwendig; wichtig ist nur, dass beim Schließen für das Typecasting der Fenstertyp bekannt ist, und das wird mit der Angabe in TWindowListData.WinTyp bereits erledigt.