(Formular-)Handling größerer Projekte

[Delbor]

Hi mm1256

Alternativ könntest du die Clientforms, die du zur Laufzeit erstellst, auch in eine (generische?) Objektliste stecken, dann müsstest du nicht alle Komponenten der Anwendung durchlaufen, sondern nur den Listeninhalt. Solltest du eine ältere Delphiversion haben, die noch keine Objectlisten kennt, kannst du auch ein TList-Objekt benutzen und da einen Zeiger ablegen.

Gruss
Delbor

[Sir Rufo]

Zitat von Delbor:

Hi mm1256

Alternativ könntest du die Clientforms, die du zur Laufzeit erstellst, auch in eine (generische?) Objektliste stecken, dann müsstest du nicht alle Komponenten der Anwendung durchlaufen, sondern nur den Listeninhalt. Solltest du eine ältere Delphiversion haben, die noch keine Objectlisten kennt, kannst du auch ein TList-Objekt benutzen und da einen Zeiger ablegen.

Gruss
Delbor

Dafür nimmt man System.Contnrs.TComponentList, denn dafür wurde die gebaut

[mm1256]

Zitat von Delbor:

Hi mm1256

Alternativ könntest du die Clientforms, die du zur Laufzeit erstellst, auch in eine (generische?) Objektliste stecken, dann müsstest du nicht alle Komponenten der Anwendung durchlaufen.....

Danke für den Tipp. Application.ComponentCount hab ich natürlich vorher mal getestet, weil, Performance möchte ich nach Möglichkeit nicht verschenken. Auch wenn's nur Kleinigkeiten sind. Es scheint so zu sein, dass Application.ComponentCount nur die Anzahl der aktiven Fenster beinhaltet. Weil ich diese ja immer wieder freigebe, wenn sie nicht mehr gebraucht werden, dürfte Application.ComponentCount i.d.R. nicht viel größer als 10 sein. Ich denke, das ist also keine Spassbremse

EDIT

Zitat von Sir Rufo:

Dafür nimmt man System.Contnrs.TComponentList, denn dafür wurde die gebaut

Geil, was ihr so alles wisst. Das kannte ich noch gar nicht.

[Sir Rufo]

Zitat von mm1256:

Es scheint so zu sein, dass Application.ComponentCount nur die Anzahl der aktiven Fenster beinhaltet.

Wenn du Application als Owner nur den Formularen gibst, was soll da auch sonst noch drin sein?

Dort ist das drin, was du da rein steckst:

Delphi-Quellcode:

program foo;

...

begin
  Application.Initialize;
  Application.CreateForm( TFooForm, FooForm ); // <- Da, wird Owner
  Application.Run;
end.

[mm1256]

Zitat von Sir Rufo:

Wenn du Application als Owner nur den Formularen gibst, was soll da auch sonst noch drin sein?

Ooooops....stimmt. Eigentlich logisch. Danke für die Erklärung.

[BadenPower]

Zitat von Delbor:

dann müsstest du nicht alle Komponenten der Anwendung durchlaufen,

Über wieviele Millisekunden reden wir hier?

Du gehst ja nicht alle Komponenten der Anwendung durch, sondern wie Sir Rufo schon richtig angemerkt hat, nur die Komponenten deren Owner "Application" ist.
Und dies sind eben meistens nur die Formulare.

[Delbor]

Hi zusammen

Zitat von BadenPower:

Zitat von Delbor:

dann müsstest du nicht alle Komponenten der Anwendung durchlaufen,

Über wieviele Millisekunden reden wir hier?

Du gehst ja nicht alle Komponenten der Anwendung durch, sondern wie Sir Rufo schon richtig angemerkt hat, nur die Komponenten deren Owner "Application" ist.
Und dies sind eben meistens nur die Formulare.

Daran hab ich erstmal nicht gedacht - mein wirklich 'rotes Tuch' ist denn auch zum Bleistift Findcomponent, das die kompletten Komponenten eines Containers durchläuft. Wenn dieser eine Form ist, kann das recht happig werden, wenn jede Komponente so identifiziert werden soll...


Gruss
Delbor

[mm1256]

Zitat von Delbor:

Daran hab ich erstmal nicht gedacht - mein wirklich 'rotes Tuch' ist denn auch zum Bleistift Findcomponent, das die kompletten Komponenten eines Containers durchläuft.....

Genauso oder zumindest so ähnlich hab ich gedacht, als ich das Beispiel von BadenPower zum ersten mal gelesen habe. Daraufhin meine größte dpr mit den schon zitierten 100+ Formularen aufgemacht, ein paar Fenster geöffnet und dann mal gecheckt, wie hoch Application.ComponentCount ist. Nach SirRufo's Kommentar ist mir dann auch schnell klar geworden, warum das so niedrig ist. Wenn man in der dpr nur ein einziges Formular (das Hauptformular) erzeugt, dann ist das wirklich eine prima Sache, und das von dir zitierte "rote Tuch" ist dann flugs samt den Vorurteilen verschwunden.

Was mich abschließend mal zu dem Kommentar verleitet: Man findet im WEB tausende von Tutorials über wie und was und überhaupt...aber wenn es mal um den Feinschliff größerer Projekte geht, wird es ganz schnell eng. Nur gut, dass es die DP gibt

[Hansa]

Bei grösseren Projekten machst Du folgendes: du baust ein Form mit vorgefertigtem caFree im OnClose. Dieses schiebst du in die Objektablage. Ab dann nur noch dieses Formulur vererben,d.h. das caFree ist standardmässig schon da und fertig. Release, free etc. wird dann nicht benötigt. Zumindest nicht bei meinem Programm mit ca, 200 Forms.

[mm1256]

Zitat von Hansa:

Bei grösseren Projekten machst Du folgendes: du baust ein Form mit vorgefertigtem caFree im OnClose.....

Das ist ja eigentlich bei größeren Projekten eine Selbstverständlichkeit. ABER: "ein Form" reicht in der Praxis nicht. Ich hab 14 MDI-Fenster in 6 Programmodulen die alle ihre grundlegenden Eigenschaften von einem Vorfahren erben. Das Selbe bei den etwa 40 modalen Dialogen, die eine Interaktion des Users erwarten, den etwa 10 Dialogen welche den Ausdruck steuern (Druck-Voreinstellungen), den etwa 50 modalen Fenstern die programmspezifische Funktionen ausführen (es geht um ein WWS).....und so weiter.

Ich hab soeben mal die Fenster zusammengezählt: 14 MDI, 27 Hauptformulare, 86 modale Dialoge, 121 Formulare mit Hilfsroutinen und dergleichen (Dateisuche, Dateien zippen, Fortschrittanzeigen, Fileviewer, Datenbank-Tools, Rechner, Scanner, Bilderanzeige...). Da sieht man erst, was sich im Lauf der Jahre in einem einzigen Projekt alles ansammelt. Die Vererbung von Formulareigenschaften (welche ja durch die Delphi-IDE wunderbar unterstützt wird) macht man sich da zwangsweise zu Nutzen. Anders geht es ja auch gar nicht. Es sei denn, man legt Wert darauf, dass das Installationsprogramm nicht mehr auf eine CD passt, nur mehr auf DVD.

Ein Beispiel für die Vererbung aus zwei unterschiedlichen Programmteilen habe ich (falls es jemand interessiert) angehängt. Der Linke ist ein Dialog im Hauptprogramm zur Datensicherung und der Rechte der Startdialog für mein Installationsprogramm (natürlich selber programmiert). Also zwei sehr unterschiedliche Bereiche. Der neue Kunde soll bereits bei der Installation auf die Programmoptik vorbereitet werden und derjenige der ein Update installiert, erkennt auf den ersten Blick um was es geht.

Der praktische Effekt: der Anwender hat in vielen Bereichen eine einheitliche Oberfläche. Der technische Aspekt: Es werden viele Ressourcen eingespart. Das bringt mich aber zurück zu einer der Ausgangsfragen:

Zitat von mm1256:

1) Gibt es hinsichtlich einer optimalen Exe-Größe bei der Include-Datei noch Optimierungsmöglichkeiten?

Hierzu hat sich noch niemand geäußert...kann ich daraus ableiten, dass hier nichts mehr zu machen ist? Mir geht es weniger um den Platzbedarf der kompletten Installation sondern um die Größe des Download-Image. Die möchte ich so klein wie möglich halten und da sind die Exe-Größen schon mit ausschlaggebend.