Wohin mit den Nicht-Visuellen Komponenten?

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