Verwaltung aller Forms eines Programms

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

[TiGü]

Zitat von 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

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.

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 von TiGü:

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.

[TiGü]

Ja, stimmt.

[himitsu]

Zitat von TurboMagic:

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.

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