Wie macht ihr das mit den vielen nicht sichtbaren Komponenten .. ? [gelöst]

[corpsman]

Hallo Zusammen,

ich entwickle hier auf arbeit ein neues GOTT Tool (ja ich weis, sowas soll man nicht machen..)

Aktuell sieht das gute Stück im Designer so aus:

Full_Form.PNG (45.75 KiB) 547 mal betrachtet

Mein Problem ist, das ich derart viele Komponenten wie Timer, TCP Connections .. habe, dass ich meine Gui schon gar nicht mehr Richtig designen kann, weil die immer im Weg sind.

Wie macht ihr das, gibt es einen Trick diese Komponenten aus zu blenden ?

[paweld]

Klicke mit der rechten Maustaste auf das Formular und deaktiviere "Show nonvisual components"

[corpsman]

lol, danke, wieder was gelernt, das kannte ich noch nicht

[Zvoni]

lol, danke, wieder was gelernt, das kannte ich noch nicht

Das mit dem Hinweis von Pawel wusste ich jetzt auch nicht.

Aber zum Thema: In solchen Fällen verbreitere ich einfach meine Form (meist nach Rechts oder Unten), wirf das Zeug dann in die Ecke, und bringe meine Form wieder dahin wo ich sie haben will von der Grösse.

[kirchfritz]

Was spricht gegen die Verwendung eines "Datamoduls"?

[corpsman]

@kirchfritz

Was ist ein Datamodule?

[kirchfritz]

Mit dem Menü "Datei"->"Neu..."->"Datenmodul" erzeugst Du für Dein Projekt ein Datenmodul, das als Container für alle unsichtbaren Komponenten gedacht ist.
Siehe auch hier: https://wiki.freepascal.org/Data_module

[af0815]

@kirchfritz

Was ist ein Datamodule?

Ähnlich wie ein nicht sichtbares Form. Verhält sich wie ein Form, das nie angezeigt (werden) kann. Dort lege ich strukturiert alles ab was ich nicht brauche. Dazu verwende ich extensiv Frames und kapsel die Funktionalität da drinnen konetxtweise.

[kirchfritz]

Guckst Du auch hier: viewtopic.php?t=7744

[corpsman]

*g* danke, und schon bin ich wieder froh meine Triviale Frage gestellt zu haben, immer wieder Toll zu sehen was es gibt und man noch nicht kennt.

[corpsman]

So hab mir das mal angesehen,

Wenn man das mit dem Datenmodul macht hat das aber den Nachteil, das die Eventhandler des z.B. TTimers nun im Datenmodul landen und nicht mehr in meiner TForm1.

Damit verliert der in dem Fall TTimer den Zugriff auf die Variablen der TForm1 (oder ich muss eben über die Uses die Unit1 wieder im Datenmodul einbenden, was eine Zirkuläre abhängigkeit rein bringt ...)

So ganz kann ich den Vorteil grad nicht sehen.. das ein und Ausblenden scheint mir da die bessere wahl zu sein ..

[fliegermichl]

Ich denke, Datenmodule sind genau dafür gedacht, weshalb sie so genannt wurden. Applikationsweite Datenverbindungen (SQL Connections, Transactions etc) zur Verfügung zu stellen.

Wenn ich in einem Formular eine Komponente benötige, sollte diese auch da definiert sein.

[Zvoni]

So hab mir das mal angesehen,

Wenn man das mit dem Datenmodul macht hat das aber den Nachteil, das die Eventhandler des z.B. TTimers nun im Datenmodul landen und nicht mehr in meiner TForm1.

Damit verliert der in dem Fall TTimer den Zugriff auf die Variablen der TForm1 (oder ich muss eben über die Uses die Unit1 wieder im Datenmodul einbenden, was eine Zirkuläre abhängigkeit rein bringt ...)

Hmm....schon mal daran gedacht, im DataModule eine Klasse von TTimer abzuleiten, welches im Create z.B. einen FunktionsZeiger-of-Object entgegen nimmt?

So ganz kann ich den Vorteil grad nicht sehen.. das ein und Ausblenden scheint mir da die bessere wahl zu sein ..

Die Quizfrage ist eher: Brauchst du diesen TTimer (bzw. die anderen Komponenten) auch noch auf anderen Formularen?
Weil wenn Nein, hat dieser auf dem DataModule nix verloren.

Ein DataModule ist eher sowas in der Art wie ein "Globaler" Container, welcher die Komponenten zur Verfügung stellt (Sofern in den Formularen/Units, welche die Komponenten verwenden wollen, das DataModule im Uses-Abschnitt ist), und den entsprechenden Code abkapselt.

Ist mit ein Grund, warum Datamodules in der "Autocreate"-Reihenfolge an erster Stelle stehen sollten

[af0815]

Bei mir steht außer dem Mainform absolut nichts auf autocreate. Das aus guten Grund, weil so habe ich den Ablauf zu 100% im meiner Hand.

Und auch Daten Module können Events bereitstellen. Damit kann ich den Timer, wenn ich will einfach nach aussen bringen. Wobei man meistens Timer dort lässt wo man sie braucht, außer man muss etwas synchron halten.

Man kann das Daten Module wie eine globale Variable verwenden. Damit ist alles Recht gut zu Kapseln, was logisch zusammen gehört.

Edit:
Es hat jeder eine andere Herangehensweise. Ich bin mit dem Autocreate schon vor Jahren bei Delphi auf die Schnauze gefallen. Vor allen wenn man ein Projekt reorganisert und mit Forms und die Erstellungsreihenfolge herumspielen muss, kann es zu Problemen kommen. Auch wenn man mal die Projektdatei raponiert, dann fängt das große Rätsel an - was kam wann drann. Und in einem großen Projekt - viel Spaß.
Deswegen halte ich da am "High Lander" Prinzip - Es kann nur einen geben - fest. Und das hat sich für mich in der Praxis von 30 Jahren bewährt.

[wp_xyz]

Wenn ich zuviele Komponenten (nicht nur nicht-visuelle) auf einem Formular habe, hilft es mir, die Funktionalitäten zusammenzufassen und in einen Frame auszulagern. Damit sind diese Komponenten und die zugehörigen Eventhandler in einer anderen Unit, und die Formular-Unit wird schlanker.

Für manche Aufgaben ist es auch nur Bequemlichkeit eine nicht-visuelle Komponente aufs Formular zusetzen. Es kostet nur ein paar Zeilen Code, diese im OnCreate des Formulars manuell zu erzeugen und ihre Eigenschaften zu setzen. Der eigentliche Zugriff auf die Komponenten benötigt sowieso eigenen Code (z.B. OpenDialog.Execute)