Komponenten mit dem Formular-Designer entwerfen

[Der schöne Günther]

Mein Ziel: Ich möchte, ausgehend von einem TFrame, eine eigene VCL-Komponente erstellen. Mit eigenen Properties und Event-Handler.

Das bekomme ich relativ flott hin und bin vom Ergebnis begeistert.

Ich glaube aber nicht, dass ich alles richtig gemacht habe, vor allem da das benutzende Projekt die .DFM-Datei des Frames im Suchpfad haben muss.

Ich gehe so vor:

• Neue Komponente, ausgehend von TFrame erstellen, in neues Package
• Die automatisch angelegte Unit kann ich wegwerfen. Das ist eine reine Unit ohne Formular dahinter.
• Ich füge meinem "Projekt" einen VCL-Frame hinzu.
• Ich bastele den Frame so zusammen, wie ich ihn haben möchte. Event-Handler, interne Logik, alles.
• Ich füge in meiner Frame-Unit (oder einer separaten) eine Prozedur "Register" ein und registriere die Kompente so wie ich es für richtig halte
• Ich installiere die Komponente

Wenn ich meine Komponente in ein lauffähiges Projekt einbauen möchte habe ich sie jetzt wie einen TButton in der Tool-Palette und kann damit anstellen, was ich mag. Allerdings muss das Projekt den Pfad, an welchem die DFM des Frames liegt im Suchpfad haben. Ich habe keine Ahnung warum.

Weiterhin bekomme ich beim Kompilieren einen Hinweis

Code:

[dcc32 Hinweis] H2161 Warning: Duplicate resource:  Type 10 (RCDATA), ID TMYFRAME; File C:\Pfad\MyComponent\TestProject\..\MyFrameUnit.dfm resource kept; file C:\Pfad\MyComponent\MyFrameUnit.dfm resource discarded.

An den Pfaden sieht man, dass es er ein und dieselbe Datei für zwei verschiedene hält.


Ich würde mich freuen wenn mir jemand erklären kann warum das benutzende Projekt die DFM zur Kompilierzeit kennen muss. Und ob ich den Kompilierhinweis abstellen oder beruhigt ignorieren kann. Und ob ich die Komponente dann auch im C++ Builder verwenden kann habe ich noch überhaupt nicht ausprobiert. Sollte gehen, oder?

[himitsu]

So richtig kann ich jetzt zwar nicht helfen, ABER

Zitat von Der schöne Günther:

Weiterhin bekomme ich beim Kompilieren einen Hinweis

Code:

[dcc32 Hinweis] H2161 Warning: Duplicate resource:  Type 10 (RCDATA), ID TMYFRAME; File C:\Pfad\MyComponent\TestProject\..\MyFrameUnit.dfm resource kept; file C:\Pfad\MyComponent\MyFrameUnit.dfm resource discarded.

An den Pfaden sieht man, dass es er ein und dieselbe Datei für zwei verschiedene hält.

das sind ja auch zwei "unterschiedliche" Dateien, auch wenn sie den selben Inhalt haben mögen. (zwei unterschiedliche Adressen)
Und nein, beim Vergleich der Pfade löst halt nicht jeder den Pfad auf, womit das für den dann eben unterschiedliche Pfade sind.

Hier liegt das Problem auch nicht am Pfad, sondern daß irgendwer die selbe Resource (der selbe Resource-Name) versucht "doppelt" einzubinden.



Ach ja, DFM-Resourcen sind Named.Resourcen, welche über den Namen der Form/Frame-Klasse gelasen werden.

Und Resourcen müssen eindeutig sein.
Es kann nur eine Resource mit dem selben Namen, bzw. mit der selben ID geben.

Wenn man mehrere Resourcen versucht in eine EXE oder DLL einzubinden, welche den selben Namen/ID haben, dann meckert natürlich der Linker rum und das zu Recht.

[Der schöne Günther]

Das sehe ich ein. Ich frage mich ja, was das benutzende Programm die DFM-Ressource der Komponente überhaupt angeht?

[Furtbichler]

Frames sind visuelle Klassen und keine Komponenten. Damit die im Designer sichtbar sind, müssen sie imho im Projekt enthalten sein. Mir macht das nichts.

Ich habe ein 'Shared' Verzeichnis, direkt neben meinen Tools. die Tools sind per Suchpfad zu finden, im Shared-Verzeichnis habe ich Formulate und Datenmodule, die Grundfunktionen bereitstellen und in jedem Projekt zu finden sind. Dort würde ich so ein Frame plazieren und eben immer mit einbinden. Ich habe z.B. Standard-Dialoge mit einem OK-Button und frei konfigurierbarer Oberfläche, Titelleiste usw. Multilingual etc. Wenn ich das brauche - wupps- eingebunden und abgeleitet. Und so ein Frame (Fällt mir gerade keins ein, was ich *immer* brauchen kann) kommt eben auch in meinen Shared-Folder.

Nebenbei habe ich auch in einem Projektordner ein Shared-Verzeichnis, weil ein Projekt auch mehrere Apps Anwendungen beinhaltet. Dort sind dann z.B. Frames zum Suchen und Anzeigen eines Kunden oder Artikels etc. Ich baue mir das Teil also 1x und verwende es dann überall. Das hat einen hohen Wiedererkennunswert und der Anwender kennt sich damit sofort aus.

Ein Frame ist nun mal keine Komponente.

[himitsu]

Du kompilierst die Frameklasse da rein, also wird auch die zugehörige DFM da mit eingebunden *1, sonst könnte der Form-Loader den Frame ja nicht laden.

1: (Meistens) über das {$R ...} in der Unit der Frame-Klasse.

[Furtbichler]

Normale Komponenten erzeugen ihre Kindkomponenten 'per Hand'.
Im Frame übernimmt das die VCL über die DFM. Und dafür muss das Frame explizit im Projekt eingebunden sein. (Oder?)

[Uwe Raabe]

Ein anderer Weg für solch wiederkehrenden, visuellen Konstrukte (Form, Frame, DataModule) ist die Objektablage. Dafür bietet sich dann so ein globaler Shared-Folder à la Furtbichler an.

Die Vorgehensweise ist recht simpel. Man designt das Form (Frame, Datamodule) und speichert es zentral ab. Dann auf dem Form im Kontextmenü "Der Objektablage zufügen" auswählen, ein paar Angaben machen (bei dem Icon auf die Größe achten! - oder es einfach so belassen) und das wars.

Die Verwendung in einem beliebigen anderen Projekt geht dann über die Objektgalerie (oder Datei - Neu - Weitere...), wobei man dort Kopieren, Vererbenoder Verwenden zur Auswahl hat.

[Patito]

Zitat von Der schöne Günther:

Mein Ziel: Ich möchte, ausgehend von einem TFrame, eine eigene VCL-Komponente erstellen. Mit eigenen Properties und Event-Handler.

Ich würde mich freuen wenn mir jemand erklären kann warum das benutzende Projekt die DFM zur Kompilierzeit kennen muss. Und ob ich den Kompilierhinweis abstellen oder beruhigt ignorieren kann.

Ich habe eine Zeit lang mit Frame-Komponenten gearbeitet. Im Vergleich zu normalen Frames war das damals schon eine Verbesserung (die Dinger sind weniger fragil). Aber irgendwann war mir der Haufen an abhängigen Packages, die mehrfach verschachtelten Komponenten produzieren zu viel und ich bin dann auf ganz andere Techniken umgestiegen... Mal sehen woran ich mich noch erinnere..

Also das .dfm braucht z.B. der Compiler für die Komponente, da darin ja die Properties der Controls im Frame stehen.
Ohne die Informationen geht nix. Bei einem Formular in einem Package ist das genauso. Ohne Positions-Informationen
sähe so ein Formular wirklich nicht gut aus.

Komerzielle Packages ohne Sourcecode haben deshalb auch immer die nötigen .DFMs bei den .DCUs dabei.

Da man beim Entwickeln .pas und das .dfm schlecht in unterschiedliche Pfade legen kann,
wird man bei Frame-Komponenten leider dahin genötigt den ganzen Sourcecode in den Library-Pfad zu stellen.

Wenn man die dfm kopiert hat man sie doppelt auf dem Rechner und das produziert auf ganz natürliche Art und Weise
Ärger.

Arbeitet man ausserdem in einem Projekt, das den Frame selbst enthält sieht der Compiler das DFM vermutlich doppelt.
Also: Frame als Komponente -> Frame aus den Projekten entfernen und nur im Package der Komponente bearbeiten.

[Furtbichler]

Zitat von Uwe Raabe:

Ein anderer Weg für solch wiederkehrenden, visuellen Konstrukte (Form, Frame, DataModule) ist die Objektablage. Dafür bietet sich dann so ein globaler Shared-Folder à la Furtbichler an

Stimmt. Hatte ich früher (und verdrängt). Mein Problem dabei: Ich kopiere das Projektverzeichnis und packe es auf einen anderen Rechner => Objektablage fehlt => Projekt kann nicht kompiliert werden.

[Der schöne Günther]

Danke für die zahlreichen Antworten

Dass die DFM auch in der benutzenden Anwendung benötigt wird habe ich verstanden. Das Dopplungs-Problem war rein meine Schuld: Irgendwie ist mir ganz oben in meine DPR der benutzenden Anwendung ein {$R '..\MyFrameUnit.dfm' :TForm(MyFrameUnit)} gerutscht. Keine Ahnung woher. Aber das war es.

Danke auch für den Hinweis mit der Objektablage bzw. dem "Der Komponentenpalette hinzufügen". So mache ich es seit dem kurz nach dem Tag als ich Frames entdeckte.

Nur habe ich mit der Tatsache,

• dass sich die Frames weiterhin (leicht ungewollt) verändern lassen (da alle enthaltenen Komponenten published sind)
• und die Dinger oft mit der Zeit langsam zusammenbröseln (siehe mein Thema hier)

große Hoffnung darin, die Dinger als reine Komponenten zu realisieren.

Eigentlich bin ich jetzt fertig. Ich baue entspannt meinen Frame als Komponente, dichte noch Events und Properties (wie ein zu benutzendes TDataSource) mit dran und sehe dann im Objektinspektor nur die ganz grundlegenden TControl -Eigenschaften und meine zugedichteten Dinge.

Hätte ich mich nur früher mal damit auseinandergesetzt.