Verwaltung aller Forms eines Programms

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