Wohin mit den Nicht-Visuellen Komponenten?

[Jazzman_Marburg]

Hallo Kollegen,
wohin packt ihr eure Nicht-Visuellen Komponeneten im Form-Designer?
Ich habe davon mittlerweile ein gutes Dutzend auf der Form liegen, und ziehe sie bei jeder Gelegenheit zur Seite, weil sie eigentlich überall nur stören (andere Dinge verdecken, die man gerade bearbeitet).
Haben die erfahrenen Delphianer einen Workaround?

Fragt sich und grüßt
Jazzman

[DeddyH]

Lies mal die Hilfe zu TDataModule.

[Ralf Kaiser]

Du könntest die Komponenten einfach auf ein Datenmodul packen. Es heisst zwar Datenmodul aber muss nicht nur Datenkomponenten enthalten!

EDIT: Grrrr. Hat der rote Kasten Urlaub???

[DeddyH]

*Hihi* schneller :zwinker:

[schlecki]

oder selbst im Quellcode erzeugen - das hat dann sogar den Vorteil, dass diese nicht als Komponenten installiert werden müssen; dadurch kann man die Libs dann leichter projektweise updaten.

[mkinzler]

Dann muss man aber auch alle Einstellungen im Code setzen

[Stevie]

Ein ganz klares: Kommt drauf an. Komponenten, die primär für GUI Funktionalitäten zuständig sind (dazu würde ich z.B. eine ActionList zählen) dann gehören sie für mich auf die Form. Hast du allerdings Dinge, wie DBConnection, Datasets (über Datasources müsst ich nochmal nachdenken, wo die für mich hingehören) kann man die in ein DataModule packen. Allein um Wiederverwendbarkeit und Trennung von GUI und BL zu gewährleisten.

P.S. Ich hasse das Erzeugen von Komponenten im Code, wenn man sie auch im Designer platzieren könnte...

[Jazzman_Marburg]

Merci! :wink:

Gruß
Jazzman

[Ralf Kaiser]

Zitat:

Zitat von Stevie (Beitrag 1105813)

Ein ganz klares: Kommt drauf an. Komponenten, die primär für GUI Funktionalitäten zuständig sind (dazu würde ich z.B. eine ActionList zählen) dann gehören sie für mich auf die Form.

Das sehe ich ein wenig anders.

Also gerade Actionlisten enthalten, zumindest meiner Meinung nach, doch grosse Teile des Business-Logik. Fügt man diese in ein Datenmodul ein so hat man die Logik in diesem Modul "gesammelt" und von der GUI, also dem Formular, getrennt.

(wobei z.B. OnUpdate-Methoden eventuell da eine "Grauzone" darstellen)

[jaenicke]

Zitat:

Zitat von mkinzler (Beitrag 1105809)

Dann muss man aber auch alle Einstellungen im Code setzen

Richtig, und das ist auch gut so. Sonst wundert man sich plötzlich warum irgendetwas nicht mehr geht, dabei hat nur jemand aus Versehen eine Eigenschaft umgestellt.

Bei größeren Projekten wird das allerdings auch unübersichtlich, wenn man das nicht gut kapselt. Deshalb ist es nicht so eindeutig was wo sinnvoll ist...

Klar ist jedenfalls eins:
Um die Oberflächen an sich von deren Logik sowie der Businesslogik und den Daten zu trennen, macht es Sinn alles auszulagern was nur geht. Wenn man das über mehrere Schichten macht, kann man leicht die Oberfläche auswechseln ohne deren Logik mit auswechseln zu müssen.

// EDIT:

Zitat:

Zitat von Alfi001 (Beitrag 1105815)

Also gerade Actionlisten enthalten, zumindest meiner Meinung nach, doch grosse Teile des Business-Logik.

Naja, eigentlich ja nicht direkt. Die entsprechenden Handler geben das ja nur (etwas aufbereitet) an die eigentliche Oberflächenbehandlung weiter.

[Neumann]

Ich würde die nichtvisuellen Komonenten auch möglichst in Datamodule oder auch auf normale Forms, die nie angezeigt werden auslagern.

Wenn es nicht geht (z.B. Mainmenu hab ich noch nicht versucht) dann kann man GExperts installieren, mit dem man diese Komponenten bei Bedarf sichtbar/unsichtbar machen kann.

[mkinzler]

Ein Menü ist ja auch irgendwie visuell

[stahli]

Das MainMenu hatte ich früher in einem DataModule liegen. Angezeigt wurde es ganz normal im MainForm.
Ich fand aber praktisch, dass das Icon während der Designzeit nicht auf dem Formular rumlag.

Diese Konstellation hat jedoch während der Entwicklung ständig die MainForm-Höhe verringert...
Das Formular wurde immer beim Öffnen (oder war es Speichern?) des Projektes um 20 Pixel oder so verkleinert.

[-187-]

Hmm bei einem Projekt habe ich eine feste Form Höhe von 200px. Diese lege ich im OnCreate der Form fest. Im Form Designer ist die Form höhe 400px und im Bereich 201-400px liegen solchen Dinge :)

Hatte auch das Problem das immer alles verdeckt wurde. Aber das mit dem Datamodule ist mit Sicherheit die bessere Variante :P

[Luckie]

Zitat:

Zitat von schlecki (Beitrag 1105808)

oder selbst im Quellcode erzeugen - das hat dann sogar den Vorteil, dass diese nicht als Komponenten installiert werden müssen; dadurch kann man die Libs dann leichter projektweise updaten.

What you can do at designtime, don't do at runtime. ;) Daran halte ich mich auch in der Regel, weil überflüssiger Code dann nicht im Quelltext auftaucht. Und wer Eigenschaften in den Komponenten verstellen kann, kann dies auch im Quelltext. Das kann also keine Begründung sein. Aber gibt es denn so viele nicht-visuelle Komponenten, dass man sich sein ganzen Formular zu pflastern kann? :gruebel: Ich schiebe sie meist irgendwo in die Ecke, wo sie nicht stören.

[himitsu]

Zitat:

Zitat von -187- (Beitrag 1105838)

Diese lege ich im OnCreate der Form fest.

Dabei setzt man aber die Höhe des Client-Bereichs und nicht Form-Höhe.
Da sich die Größe der Titelleiste und der Rahmen ändern kann.
Außerdem beschränkt man so die Benutzer, welche die Form skalieren wollen.

[Hansa]

Zitat:

Zitat von Luckie (Beitrag 1105842)

What you can do at designtime, don't do at runtime. ;)

Warum schreibst Du das nicht auf Deutsch ? So verstehts ja keiner. :shock: :lol:

Ich muss das aber etwas erweitern bzw. relativieren : Don't do something at runtime, if you don't know, how much you need. Also, wenn man zur Designtime nicht genau weiss, wieviele Komponenten man braucht, dann werden die eben zur Laufzeit erzeugt. Dafür einen sinnvollen Einsatzzweck zu haben ist gar nicht so einfach. Allerdings habe ich ein Beispiel wo es kaum anders geht : Touchscreen zur Warenerfassung. Zuerst stehen da die Warengruppen auf der Form als Panele. Ist eine ausgewählt, dann sollen die Artikel angezeigt werden etc. Wieviele Panele es gibt, das hängt dann davon ab, wieviele Warengruppen/Artikel angelegt sind.

Für das Ganze wird dann eine Form mit Panelen zugekleistert. Dabei muss alles codemässig gesetzt werden : die Koordinaten, der Name, Caption, OnClick usw., eben alles vom Programm. Da die Anzahl der Datensätze zur Designtime nicht bekannt ist, kann ich also auch nicht einfach zur Designtime eine gewisse Anzahl an Panelen auf die Form klatschen und sie in Position bringen.

Zur Frage an sich : alles gehört dahin, wo die Programmlogik auch ist. Sollte dieser Touchscreen z.B. noch einen Timer brauchen für Uhrzeitanzeige oder so, dann kommt der auch auf die entsprechende Form und nicht etwa in ein Datamodul, nur weil er nichtvisuell ist. Ich habe sogar 4 Datamodule, weil nur eines überlaufen würde. :lol: Was jetzt wo drin ist, das hängt einzig und allein von der Programmlogik ab. Oder vom Typ. Stored Procedures sind z.B. überwiegend in einem Datamodule. D.h. die sind nicht zwingend da, meistens jedoch schon.

Und es gibt noch anderes nichtvisuelles, nicht nur Komponenten. Irgendwelche Funktionen etc. Die kommen in eigene Unit. Das ist dann so was wie Netto, Brutto usw. Umgekehrt rum gibts auch Datasets direkt auf einer Form. Das wäre dann so etwas, was nur die eine Form betrifft. Warum soll ich auch noch damit das Datamodul belästigen ? :cyclops:

P.S.: was heisst übrigens "gutes Dutzend" ? Von was ? Das kann man ja wirklich locker in die Ecke schieben. :mrgreen:

[mschaefer]

Allgemeines geht ins DataModul und sonst neige ich zu einem Panel am unteren Formularrand, was auf visible=false gestellt ist. Man kann dann sogar Bereiche unterteilen mit SubPanels. Aber das ist nur bei wenigen großen Projekten nötig.

[Stevie]

Zitat:

Zitat von Alfi001 (Beitrag 1105815)

Zitat:

Zitat von Stevie (Beitrag 1105813)

Ein ganz klares: Kommt drauf an. Komponenten, die primär für GUI Funktionalitäten zuständig sind (dazu würde ich z.B. eine ActionList zählen) dann gehören sie für mich auf die Form.

Das sehe ich ein wenig anders.

Also gerade Actionlisten enthalten, zumindest meiner Meinung nach, doch grosse Teile des Business-Logik. Fügt man diese in ein Datenmodul ein so hat man die Logik in diesem Modul "gesammelt" und von der GUI, also dem Formular, getrennt.

(wobei z.B. OnUpdate-Methoden eventuell da eine "Grauzone" darstellen)

Ich sagte ActionList, und nicht die Events davon... Angenommen, du hast nen MenuItem im MainMenu, eins in nem PopupMenu und noch nen ToolButton. An alle 3 kommt die gleiche Action. Dann kommt das Event ins DataModule (oder sonstwo hin, aber nicht ins Form!) aber die ActionList kann locker aufm Form bleiben.

[BUG]

Zitat:

Zitat von Hansa (Beitrag 1105854)

Warum schreibst Du das nicht auf Deutsch ? So verstehts ja keiner. :shock: :lol:
[...]
Don't do something at runtime, if you don't know, how much you need. Also, wenn man zur Designtime nicht genau weiss, wieviele Komponenten man braucht, dann werden die eben zur Laufzeit erzeugt.

Also du bleibst wirklich besser beim Deutschen :stupid:

[divBy0]

Du könntest die Komponenten auch mit den GExperts ausblenden / verstecken.

[Sir Rufo]

Das Auslagern macht nur dann Sinn, wenn die entsprechenden Komponenten mehrfach benutzt werden können/sollen und dabei nicht zum Sperrkriterium werden, wenn von der Form mehrere Instanzen benötigt werden.

Beispiel:

Habe ich ein Formular zur Suche in einer Datenbank und die Query für die Suche in einem DatenModul, dann greift jede Formular Instanz auf die zur DesignTime verbundene DatenModul Instanz zu.
Um das zu umgehen, müsste man für jede Form Instanz eine Instanz vom DatenModul erzeugen und die Verbindungen zu den Komponenten der Form Instanz herstellen (DBGrid, DBEdits, etc.)
Und wehe man vergisst eine zur DesignTime eingestellte Verbindung.

Aus diesem Grund würde bei mir diese QueryKomponente nebst DataSource auf das Formular kommen und nicht ausgelagert in einem DatenModul.

[Hansa]

Zitat:

Zitat von BUG (Beitrag 1105894)

Also du bleibst wirklich besser beim Deutschen :stupid:

Auch Du mein Sohn Brutus brauchst einen maschinellen Übersetzer ? :mrgreen: