Verwaltung aller Forms eines Programms

[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.

[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)

[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.

[Rollo62]

Wäre es nicht besser die Forms gleich dynamisch zu generieren, und OnDemand zu generieren und zu starten ?
Das würde mit einer kleinen Scriptsprache, oder einer intelligenten Basis-Form oder Frame doch kaum Aufwand sein.

[TiGü]

Ich werfe eine erste Idee in den Raum, ausgehend davon, was wir schon wissen.
Geht bestimmt noch besser, eleganter, flexibler und/oder nehme-doch-dieses-Framework-ist-ja-alles-schon-drin.
Ist nur eine Diskussionsgrundlage.

Delphi-Quellcode:

program FormManagerDemo;

uses
  Vcl.Forms,
  FormManager in 'FormManager.pas',
  Unit1 in 'Unit1.pas' {MainForm},
  Unit2 in 'Unit2.pas' {Form2},
  Unit3 in 'Unit3.pas' {Form3};

{$R *.res}

begin
  ReportMemoryLeaksOnShutdown := DebugHook <> 0;
  Application.Initialize;
  Application.MainFormOnTaskbar := True;
  Application.CreateForm(TMainForm, MainForm);
  GetFormManager.RegisterForm(TForm2);
  GetFormManager.RegisterForm(TForm3);
  Application.Run;
end.

Delphi-Quellcode:

unit FormManager;

interface

uses
  System.SysUtils, System.Classes,
  System.Generics.Collections,
  Vcl.Forms;

type
  TFormManager = class(TObject)
  private
    class constructor Create;
    class destructor Destroy;
  private
    FContainer: TObjectDictionary<TFormClass, TForm>;
  public
    constructor Create;
    destructor Destroy; override;

    function GetForm<T: class, constructor>: T;
    procedure RegisterForm(const AFormClass: TFormClass);
  end;

function GetFormManager: TFormManager;

implementation

var
  _FormManager: TFormManager;

function GetFormManager: TFormManager;
begin
  Result := _FormManager;
end;

constructor TFormManager.Create;
begin
  inherited;
  FContainer := TObjectDictionary<TFormClass, TForm>.Create([doOwnsValues]);
end;

class constructor TFormManager.Create;
begin
  _FormManager := TFormManager.Create;
end;

class destructor TFormManager.Destroy;
begin
  _FormManager.Free;
end;

destructor TFormManager.Destroy;
begin
  FContainer.Free;
  inherited;
end;

function TFormManager.GetForm<T>: T;
var
  LForm: TForm;
begin
  if FContainer.TryGetValue(TFormClass(T), LForm) then
  begin
    if not Assigned(LForm) then
    begin
      LForm := TFormClass(T).Create(nil);
      FContainer.AddOrSetValue(TFormClass(T), LForm);
    end;
    Result := T(LForm);
  end else
  begin
    Result := nil;
  end;
end;

procedure TFormManager.RegisterForm(const AFormClass: TFormClass);
begin
  FContainer.Add(AFormClass, nil);
end;

end.

Delphi-Quellcode:

unit Unit1;

interface

uses
  System.Classes,
  Vcl.Controls, Vcl.Forms, Vcl.StdCtrls,
  Unit2, Unit3;

type
  TMainForm = class(TForm)
    btnForm2: TButton;
    btnForm3: TButton;
    procedure btnForm2Click(Sender: TObject);
    procedure btnForm3Click(Sender: TObject);
  private
  public
  end;

var
  MainForm: TMainForm;

implementation

{$R *.dfm}

procedure TMainForm.btnForm2Click(Sender: TObject);
begin
  Form2.ShowModal;
end;

procedure TMainForm.btnForm3Click(Sender: TObject);
begin
  Form3.ShowModal;
end;


end.

Delphi-Quellcode:

unit Unit2;

interface

uses
  System.SysUtils, System.Classes,
  Vcl.Controls, Vcl.Forms, FormManager;

type
  TForm2 = class(TForm)
  end;

  function Form2: TForm2;

implementation

{$R *.dfm}

function Form2: TForm2;
begin
  Result := FormManager.GetFormManager.GetForm<TForm2>;
end;

end.

Delphi-Quellcode:

unit Unit3;

interface

uses
  System.SysUtils, System.Classes,
  Vcl.Controls, Vcl.Forms, FormManager;

type
  TForm3 = class(TForm)
  end;

  function Form3: TForm3;

implementation

{$R *.dfm}

function Form3: TForm3;
begin
  Result := FormManager.GetFormManager.GetForm<TForm3>;
end;

end.

[Rollo62]

Als Anregung, wenn Du die Forms wirklich Alle schon statisch registrieren möchtest.
Mach das besser nicht in der DPR, sondern in jedem FormUnit, z.B. per initialization

Delphi-Quellcode:

unit Unit1;

interface

uses
  System.Classes,
  Vcl.Controls, Vcl.Forms, Vcl.StdCtrls,
  Unit2, Unit3
  , MyFormManager
  ;

type
  TMainForm = class(TForm)
  ...
  private
  public
  end;

var
  MainForm: TMainForm;

implementation

{$R *.dfm}

initialization
    TMyFormManager.RegisterForm( 'MainForm', TMainForm);

end.

So behältst Du die DPR sauber, und die Units registrieren sich selbst beim Einbinden der Unit,
ohne dass Du etwas dazu machen musst.

[Sinspin]

Zitat:

Zitat von DieDolly (Beitrag 1480380)

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.

[TiGü]

Zitat:

Zitat von Rollo62 (Beitrag 1480414)

Als Anregung, wenn Du die Forms wirklich Alle schon statisch registrieren möchtest.
Mach das besser nicht in der DPR, sondern in jedem FormUnit, z.B. per initialization

So behältst Du die DPR sauber, und die Units registrieren sich selbst beim Einbinden der Unit,
ohne dass Du etwas dazu machen musst.

Möglich, da waren wir aber vor sieben Jahren schon weiter bzw. war damals Stand der Dinge, dass dies keine gute Idee ist (ab Beitrag #14):
https://www.delphipraxis.net/178976-...gesucht-2.html

Das registrieren in der DPR wäre ja nur der erste Schritt, da dies mit suchen und ersetzen (Application.CreateForm -> IrgendwieDieReferenzAufDenFormManager.RegisterForm ) leicht zu realisieren ist.
An einen müßigen Nachmittag kann man das dann an natürlich verschieben.


Nach dem dritten Kaffee ist mir auch die Idee gekommen, das registrieren erst beim erstmaligen Aufruf zu realisieren.
So würde die Methode RegisterForm komplett wegfallen.
Das hätte in der richtigen Applikation den Vorteil, dass man ggf. neben der Mainform nur die Formulare erzeugt und registriert, die der Benutzer im jeweiligen "Durchlauf" wirklich benötigt.
Kennt ja jeder von sich selbst: Delphi-IDE, Excel und Word bieten eine Vielzahl an Oberflächen, für das schnelle Konsolenprogramm oder einen einfachen Brief brauche ich aber nichts weiter als das Hauptformular.

Der von mir vorgeschlagene Form-Manager verkürzt sich dann zu:

Delphi-Quellcode:

function TFormManager.GetForm<T>: T;
var
  LForm: TForm;
begin
  if not FContainer.TryGetValue(TFormClass(T), LForm) then
  begin
    LForm := TFormClass(T).Create(nil);
    FContainer.AddOrSetValue(TFormClass(T), LForm);
  end;
  Result := T(LForm);
end;

// TFormManager.RegisterForm und die Aufrufe können gelöscht werden

[Uwe Raabe]

Keine Ahnung, ob das relevant ist, aber der Ansatz hat den Nachteil, dass immer nur eine Instanz einer Form-Klasse existieren kann.

Ich sehe auch jetzt keinen wirklichen Vorteil in einem speziellen Form-Manager gegenüber der Nutzung von Screen.Forms[]. Jede TCustomForm/TForm-Instanz registriert sich in Screen.Forms/CustomForms in der InitializeNewForm Methode und entfernt sich im Destroy wieder. Eine simple Iteration findet ein Form nach jedem halbwegs sinnvollem Kriterium (Name, Klasse, ...). Will man es komfortabler, schreibt man einen Wrapper (z.B. class helper for TScreen). Der Regsutrierungs-Mechanismus ist vorhanden und erfordert keinen zusätzlichen Code. Warum sollte man das nicht nutzen?

Delphi-Quellcode:

type
  TScreenHelper = class helper for TScreen
  public
    function FindOrCreate<T:TForm>(const AName: string = ''): T;
  end;

function TScreenHelper.FindOrCreate<T>(const AName: string): T;
var
  frm: TForm;
  I: Integer;
begin
  for I := 0 to FormCount - 1 do begin
    frm := Forms[I];
    if (frm.ClassType = T) and ((AName = '') or SameText(AName, frm.Name)) then
      Exit(T(frm));
  end;
  Result := T.Create(nil);
  if AName > '' then begin
    Result.Name := AName;
  end;
end;

...

begin
  myForm := Screen.FindOrCreate<TMyForm>;
  myForm2 := Screen.FindOrCreate<TMyForm>('myForm2');
end;