![]() |
AW: Viele Formulare in einem Projekt
Zitat:
Einfach ins Programmverzeichnis legen reicht vollkommen. Dann könnten sogar mehrere Programme unterschiedliche VCL-Versionen nutzen. |
AW: Viele Formulare in einem Projekt
Zitat:
Ein (für uns) Hauptgrund gegen Packages ist aber das man in den mitgelieferten Packages keine selbst eingepflegten Patches rein bekommt. |
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. |
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
|
AW: Viele Formulare in einem Projekt
Zitat:
|
AW: Viele Formulare in einem Projekt
Zitat:
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. |
AW: Viele Formulare in einem Projekt
Zitat:
|
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. |
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. |
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 20:30 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz