Delphi-PRAXiS
Seite 2 von 3     12 3      

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Algorithmen, Datenstrukturen und Klassendesign (https://www.delphipraxis.net/78-algorithmen-datenstrukturen-und-klassendesign/)
-   -   Viele Formulare in einem Projekt (https://www.delphipraxis.net/176938-viele-formulare-einem-projekt.html)

himitsu 6. Okt 2013 19:14

AW: Viele Formulare in einem Projekt
 
Zitat:

VCL-Packages muss man global für den ganzen Rechner installieren.
Nein.

Einfach ins Programmverzeichnis legen reicht vollkommen.
Dann könnten sogar mehrere Programme unterschiedliche VCL-Versionen nutzen.

Bernhard Geyer 6. Okt 2013 22:11

AW: Viele Formulare in einem Projekt
 
Zitat:

Zitat von himitsu (Beitrag 1230989)
Dann könnten sogar mehrere Programme unterschiedliche VCL-Versionen nutzen.

Können Sie auch so seit die Packages (seit D3?) mit Versionnummern (VCL30.bpl, VCL40.bpl, ...) versehen sind.

Ein (für uns) Hauptgrund gegen Packages ist aber das man in den mitgelieferten Packages keine selbst eingepflegten Patches rein bekommt.

himitsu 6. Okt 2013 23:16

AW: Viele Formulare in einem Projekt
 
Ich meinte vorallem innerhalb einer Hauptversion.

Mit Updates, Hotfixes, Fixpacks usw. kommt man da nicht so schön zurecht.

mkinzler 7. Okt 2013 11:15

AW: Viele Formulare in einem Projekt
 
Grundsätzlich funktioniert dass auch bei nichtmodalen Fenstern. Man muss diese nur so konfigurieren, dass diese bei Schliessen freigegeben werden

Bjoerk 7. Okt 2013 12:43

AW: Viele Formulare in einem Projekt
 
Zitat:

Zitat von dr. jack1 (Beitrag 1230905)
Da das Projekt ehr noch wächst, ist es für mich sicherer es im Vorfeld schon zu wissen...

Würde sagen, kommt drauf an, was die Forms in ihren FormCreates so alles erzeugen und ob eine Form von mehreren Forms verwendet wird. Die Forms lokal bzw. unitglobal zu erzeugen kann schnell ziemlich unübersichtlich werden und auch zu Fehlern führen (Form1.Form101.List <> Form2.Form101.List <> AForm101.List).

musicman56 7. Okt 2013 13:25

AW: Viele Formulare in einem Projekt
 
Zitat:

Zitat von Bjoerk (Beitrag 1231023)
Zitat:

Zitat von dr. jack1 (Beitrag 1230905)
Da das Projekt ehr noch wächst, ist es für mich sicherer es im Vorfeld schon zu wissen...

Würde sagen, kommt drauf an, was die Forms in ihren FormCreates so alles erzeugen und ob eine Form von mehreren Forms verwendet wird. Die Forms lokal bzw. unitglobal zu erzeugen kann schnell ziemlich unübersichtlich werden und auch zu Fehlern führen (Form1.Form101.List <> Form2.Form101.List <> AForm101.List).

ich würde sagen, das ist dann aber eher ein Design-Problem :roll:

Die Vor- und Nachteile der Formularerzeugung zur Laufzeit habt ihr ja schon durch. Auf die meiner Meinung nach wichtigste Frage seid ihr jedoch noch nicht eingegangen, bzw. hat der TE gar nicht hingewiesen: wird eine Datenbank verwendet, d.h. werden in den Formularen Datenbankinhalte angezeigt? In diesem Fall ist das Erzeugen aller Formulare :cyclops::cyclops::cyclops: da alle DB-Controls fortlaufend aktualisiert werden müssen.

Bjoerk 7. Okt 2013 17:38

AW: Viele Formulare in einem Projekt
 
Zitat:

Zitat von Bjoerk (Beitrag 1231023)
ich würde sagen, das ist dann aber eher ein Design-Problem :roll:

Aha. Was soll denn daran bitte ein Designproblem sein, wenn eine Form von mehreren anderen benutzt wird? Am Beispiel der DB hast du es doch selbst schön erläutert, daß nämlich in dem Fall diese Forms global sein müssen?

Medium 7. Okt 2013 22:07

AW: Viele Formulare in einem Projekt
 
Eine Form sollte tunlichst NIE von irgendwem benutzt werden! Im Gegenteil: Die Forms bedienen sich selbst aus Feldern der unterliegenden Geschäftslogik. Sorum wird ein Schuh draus, alles andere ist ist eine wartende Wartungshölle oberster Güte.

Ähnlich bei DB-Controls: Ich finde die Dinger ziemlich böse. DB-Connections werden bitte ebenfalls zwischen Daten- und Geschäftslogik Schicht eingerichtet, und ein Formular darf sich dann freundlicherweise bei dieser Schnittstelle bedienen. Aber man pumpt ihm nichts von hinten rein!

Der Hinweis auf grobe Designfehler ist hier mehr als gerechtfertigt.

jaenicke 7. Okt 2013 23:55

AW: Viele Formulare in einem Projekt
 
Ich selbst habe etwas ähnliches schon einmal umgesetzt:
Einen Pool, der die verschiedenen Module der Anwendung bereit stellt. Wenn ich jetzt das Formular XY anzeige, fragt dieses beim Laden die passende Businesslogik usw. von diesem Pool an. Ist sie bereits geladen, wird diese benutzt, andernfalls geladen.

Besonders interessant wurde das dadurch, dass alle Module nach dem Programmstart asynchron mit Abhängigkeiten und benutzerspezifischen Prioritäten geladen wurden. Diese Prioritäten werden statistisch aus den nach einem Programmstart zuerst angeklickten Modulen des Benutzers ermittelt, so dass statistisch meistens das am häufigsten nach dem Programmstart geladenen Modul auch bereits vorgeladen war.
Wenn nicht, wird es im Pool priorisiert, so dass es als nächstes geladen wird.

Auf diese Weise wurde aus einer Startzeit von ca. 2,5 Minuten eine Startzeit von 1-2 Sekunden, in aller Regel ohne eine spürbare Beeinträchtigung durch längere Ladezeiten während das Programm läuft. Der Splashscreen fiel dann auch weg, weil es schlicht nicht mehr viel zu laden gab.

Was ich damit sagen will:
Die Formulare sind doch in der Regel gar nicht das Problem, sondern die Logik dahinter. Die hat aber mit den Formularen selbst erst einmal nichts zu tun.

scheufens 9. Nov 2013 15:01

AW: Viele Formulare in einem Projekt
 
Hi,
unser ERP besteht aus über 300 Formularen.
Wir erzeugen Formulare NIE automatisch!

Gruß
Bernd


Alle Zeitangaben in WEZ +1. Es ist jetzt 04:23 Uhr.
Seite 2 von 3     12 3      

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz