Verwaltung aller Forms eines Programms

[hgf]

Hallo Delphi-Praxis,

ich will in einem großen Projekt (1500+ Forms) alle globalen Variablen entfernen. Dies betrifft auch die Formvariablen, die bei der Formerstellung automatisch von Delphi angelegt werden. Bisher hat der Zugriff auf jede Form über die eigene globale Variable stattgefunden.

Meine erste Idee hierzu war, dass ich alle erstellten Formen in einer Liste (TObjectList o.ä.) auf der MainForm verwalte. Die Formvariablen könnte ich durch ein Hilfsprogramm zu Funktionen ändern, welche mir dann die gewünschte Form aus dieser Liste heraussucht und zurückliefert. Dazu noch eine globale Funktion, die dann die erstellte Form in die Liste aufnimmt oder wieder auf nil setzt.

Habt ihr mit so einer Lösung Erfahrung? Wie sieht die Performance damit aus?
Habt ihr andere Lösungen für dieses Problem gefunden?
Tipps und Hinweise für das Entfernen von globalen Variablen sind auch willkommen.

Vielen Dank im Voraus,
hgf

[freimatz]

Ich erzeuge weitere Formulare generell zur Laufzeit und verwende gar keine globalen Variablen dazu.
1500+ ist schon eine ganze Menge.
Wenn TObjectList dann besser TObjectList<TForm>.
Nicht auf die MainForm, sondern in eine separate unit namens FormManager o.ä., die dann die MainForm benutzt.
Das Zeitverhalten halte ich für völlig unkritisch. Ggf. ist ein TDictionary besser.
Wenn man es nach aussen gut kapselt dann kann man das interne immer noch später austauschen.

[haentschman]

Zitat:

Ggf. ist ein TDictionary besser.

+1 :thumb:

Zitat:

1500+ ist schon eine ganze Menge.

:shock:

[Uwe Raabe]

Zitat:

Zitat von hgf (Beitrag 1480363)

Meine erste Idee hierzu war, dass ich alle erstellten Formen in einer Liste (TObjectList o.ä.) auf der MainForm verwalte.

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

[mkinzler]

Zitat:

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

Jein.

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

[Redeemer]

Zitat:

Zitat von freimatz (Beitrag 1480367)

Ggf. ist ein TDictionary besser.

Mit was für Typen und wofür? Warum nicht TObjectDictionary? Beachte, dass mehrere Forms mit dem Namen

Delphi-Quellcode:

''

existieren dürfen.

[Uwe Raabe]

Zitat:

Zitat von mkinzler (Beitrag 1480371)

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.

[venice2]

Zitat:

Zitat von Uwe Raabe (Beitrag 1480379)

Zitat:

Zitat von mkinzler (Beitrag 1480371)

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

Wieso? Was sollte diese Variable denn enthalten?

Forms? LOL :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:

Zitat von venice2 (Beitrag 1480381)

Zitat:

Zitat von Uwe Raabe (Beitrag 1480379)

Zitat:

Zitat von mkinzler (Beitrag 1480371)

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

Wieso? Was sollte diese Variable denn enthalten?

Forms? LOL :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...

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

[TiGü]

Immer wenn man denkt: "So, dass passt so, geht kaum noch einfacher", kommt Uwe und haut so einen Knüller raus. :thumb:

Wobei ich aus Komfortgründen den Owner bei T.Create statt nil ggf. Application.MainForm mitgeben würde.
So spart man sich weitere Logik für das Freigeben.
Kommt aber natürlich auf den Anwendungsfall an.

[Uwe Raabe]

Zitat:

Zitat von TiGü (Beitrag 1480451)

Wobei ich aus Komfortgründen den Owner bei T.Create statt nil ggf. Application.MainForm mitgeben würde.
So spart man sich weitere Logik für das Freigeben.

Dann wäre Application vielleicht die bessere Wahl. Das wäre zumindest konform mit der automatischen Erzeugung.

[hgf]

Ich danke euch für die guten und vielen Antworten. Da ich meinen Fall nur recht allgemein formuliert habe, sind einige vorgeschlagene Lösungen leider nicht anwendbar.

Das Programm läuft bisher ganz normal auf dem Desktop. Der Benutzer startet die .exe und beendet das Programm nach der Benutzung. Ich will es so ändern, dass es über einen WebBrowser aufrufbar ist. Das Programm soll dann also auf einem Server laufen, und mehrere Sitzungen verwalten können. Wenn nun aber im Programm eine globale Variable gesetzt wird, dann gilt die für das komplette Programm, also auch sitzungsübergreifend. Somit könnte der Fall auftreten, dass Sitzung A auf eine Form von Sitzung B zugreifen kann. Dies darf natürlich nicht geschehen. Deshalb müssen alle globalen Variablen entfernt oder dahingehend geändert werden, dass sie nur je Sitzung global sind.
Diese Umstellung soll mit möglichst wenig Aufwand geschehen. Der Vorschlag von Uwe Raabe mit Screen.Forms geht leider nicht, da die Forms nicht auf dem Server angezeigt werden. Dass es dabei nur eine Instanz jeder Form-Klasse geben kann ist egal, solange es eine Instanz pro Sitzung, und nicht je Server, ist.
Ich denke deshalb, dass es auf irgendeine Art und Weise einen Form-Manager geben muss. Die Frage ist nur, welche Lösung sich kaum auf die Performance auswirkt und ohne großen Aufwand umgesetzt werden kann.

Für euere Vorschläge, Tipps und Hinweise bin ich dankbar.

[TiGü]

Ja, stimmt.

[himitsu]

Zitat:

Zitat von TurboMagic (Beitrag 1480391)

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

Und auch ob wirklich ALLE Forms bei Programmstart geladen werden.
Screen.Forms hilft nur, wenn alle Forms dort geladen sind.

Wenn man die meisten Forms nur dann erstellt, wenn sie wirklich benutzt werden, dann braucht man eine Liste der TFormClass, bzw. könnte auch über die RTTI gehn.



Es gab irgenwo ein Projekt/Komponente, die sich an eine VCL-Form hängt und das auf einen Canvas im Browser umbiegt (kopiert), bzw. die Klicks von dort in Anwendung/Form zurück schickt.
Aber davon würde ich eher abraten.
Abgesehn davon: ALLE Forms laden, dann noch das Programm mehrmals starten ... da braucht man dann einen sinnlos unnötig großen Rechner.

Da gibt es für Web-Application wesentlich bessere Methoden, aber bedeutet natürich erstmal ein paar Umbauarbeiten.
Selbst Borland hat/hatte da was, womit deren altes BDN/EDN Webseite gebaut war, aber das will wohl niemand feiwillig benutzen, wenn er sieht/sah wie "flott" das dort läuft/lief.



PS:
Bei uns sind die Forms in DLLs verteilt und werden über DLL-Exports eingebunden.
= Aufruf über DLLName+ExportMethode, bzw. über eine MappingTabelle mit TFormKlassenName->DLLName+ExportMethode

Zusätzlich gibt es DFMs für Eingabemasken in einer Tabelle. Daraus wird beim Schließen ein SQL generiert und benutzt, oder als WHERE für das nächste Fenster benutzt.
Solche DFMs, zusammen mit einem Scripting, könnte man auch direkt benutzen.
Script-Sprachen gibt es Viele (sogar mehrere PascalScript) und es gibt von mehreren Anbietern auch einen FormDesigner und ObjektInspektor, zum Einbau ins eigene Programm.

[Uwe Raabe]

Zitat:

Zitat von himitsu (Beitrag 1480507)

Wenn man die meisten Forms nur dann erstellt, wenn sie wirklich benutzt werden...

Wenn du mit den Forms sinnvoll arbeiten willst, brauchst du eh die Form-Unit in der uses-Anweisung. Dann reicht auch ein entsprechender Aufruf wie in meinem Beispiel um das Form zu erzeugen bzw. ein bereits bestehendes zu finden.

Mir ist schon klar, dass der Ansatz bei einer Web-Anwendung mit mehreren Sessions nicht sinnvoll ist. Wenn diese Sessions dann noch in separaten Threads ablaufen ist mit VCL eh nicht mehr viel zu machen. Dafür gibt es ja auch entsprechende Frameworks, die genau für diese Problematik entwickelt wurden.

[MyRealName]

Ich würde wahrscheinlich auch einfach eine form factory nutzen, wo ich mit dem Klassennamen (als String) die Form-Klasse suche und dann eine Instanz davon erzeuge. Dazu noch ein Interface mit InitForm, SaveForm (vielleicht, wenn gebraucht) und CloseForm Methoden. UNd dann alles generisch nutzen.
Zum Speichern, wie Uwe schon sagte, die vorhandene Form-Liste oder, falls man was spezielles brauch, einfach eine TObjectList. Dazu kann man sich ja noch interface-Methoden einfallen lassen, um zusätzliche Informationen zum Form rauszufinden.

Ich hab mal an einem 1000+ Forms Projekt gearbeitet, wo ich keine globalen Form Variablen nutzte (hab ich als erstes mit rausgeworfen) und hab es über MDI da gemacht (wo design-technisch so vorgegeben). Und dann eine gute Form Hierarchie dazu gebaut, und hab dann entsprechend abgeleitet vom Level in der Hierachie, welches ich brauchte. MIttlerweile würde ich das vielleicht auch schon wieder eher mit interfaces machen, aber man entwickelt sich ja auch weiter :)

[hgf]

Danke euch für die Antworten. Und ein besonderes Danke an Uwe Raabe für den Hinweis mit dem Screen.Forms.
Ich habe in der Klasse, die die verschiedenen Sitzungen verwaltet, dieselbe Funktionalität gefunden. Somit hat sich mein Problem erledigt.