Neue Komponente mit 2 TEdit Komponenten

[Optiplex]

Hallo,
ich muss eine Komponente mit 2 Editfeldern und 6 Feldern mit Textausgabe erstellen. Bevor ich damit beginne wollte ich eure Meinung hören wie man das am besten angeht. Verwende ich TEdit oder besser TCustomEdit? Wie erzeuge ich die Editfelder an besten?Wie bekomme ich die Onchance Ereignise der Editfelder in ein gemeinsames OnChance Ereignis? Wie positioniert man die Editfelder auf seiner Komponente? usw. Ich bin für jeden Hinweis und Erklärung dankbar denn mit solchen zusammengesetzten Komponenten habe ich mich überhaupt noch nicht beschäftigt.

Gruss
Dieter

[Bernhard Geyer]

Schau dir doch mal die TFrame-Komponente an.

[mkinzler]

TCustom<Kompo> sind die dafür geschaffenen Basisklassen

[freak4fun]

Hallo,
schau mal bei dsdt.info. Hier ist zum Beispiel ein Tutorial. Ich hoffe das hilft dir weiter.

[Satty67]

Falls schon etwas Basiswissen da ist, ist vielleicht auch der Quellcode von LabeledEdit ganz interessant. Der ist ja bei Delphi mit dabei (zumindest in der kostenlosen Turbo 2006, hoffe dann auch in der 2005 PE?).

[Optiplex]

Hallo zusammen,
danke für eure schnellen Antworten.

Zitat von mkinzler:

TCustom<Kompo> sind die dafür geschaffenen Basisklassen

Beim Vorfahrtyp habe ich eigendlich an TCustomControl gedacht, weil dort den Canvas schon integriert ist und so die Textausgaben keine großen Probleme bereiten. Mein Großes Problem sind diese Editfelder wie bekomme ich diese auf die Komponente und kann die Eingaben auswerten(deshalb das OnChanche in das die beiden OnChance Ereignisse der Edits auslösen sollen).

Zitat von Satty67:

Falls schon etwas Basiswissen da ist, ist vielleicht auch der Quellcode von LabeledEdit ganz interessant. Der ist ja bei Delphi mit dabei (zumindest in der kostenlosen Turbo 2006, hoffe dann auch in der 2005 PE?).

Nein bei der 2005PE sind keine Quellcodes dabei, würde mir auch nichts nützen da ich keine Komponente kenne die 2 Editfelder besitzt.

Zitat von Bernhard Geyer:

Schau dir doch mal die TFrame-Komponente an.

Mir dieser Frame Komponente habe ich bisher überhaupt noch nicht gearbeitet.


Dieter

[Satty67]

Zitat von Optiplex:

...würde mir auch nichts nützen da ich keine Komponente kenne die 2 Editfelder besitzt.

Ich dachte Du willst Sie doch selber erstellen und nicht eine fertige Komponente? TLabeledEdit hätte ja nur gezeigt, wie man z.B. zwei TEdit's in einer Komponente leicht kombinieren und positionieren könnte. Aber dafür extra TDE2006 installieren um an die Sourcen zu kommen ist natürlich zuviel Aufwand.

TFRame ist einfach, Menü -> Datei -> Neu -> Frame. Ist dann wie ein neues Formular, in das man seine Einzelkomponenten plazieren kann. Das ergebnis ist aber mE. keine neue Komponente, sondern eben ein Frame.

[shmia]

Zitat von Optiplex:

Bevor ich damit beginne wollte ich eure Meinung hören wie man das am besten angeht.

Man sollte eigentlich nicht mehrere Controls (2 sollte die Obergrenze sein) zu einer neuen Komponente zusammenfassen.
Gründe:
* unflexibel, die Komponente verbirgt das Innenleben meistens so stark, dass man häufig die Schnittstelle der Komponente ändern muss
* umständliche Weitergabe des Projekts - das Installieren der Komponente nervt
* die Komponente lässt sich nur in einem Projekt verwenden, weil sie zu speziell ist
* wenn man öfters solche Spezialkomponenten erstellt, müllt man sich die IDE zu und schleppt den Code im Speicher mit

Wie Bernhard Geyer schon gesagt hat, wäre ein Frame hier das Richtige.
Dabei wichtig: vom Formular aus möglichst nicht direkt auf die Controls auf dem Frame durchgreifen,
sondern über Properties abkapseln.

[oki]

Zitat von shmia:

Dabei wichtig: vom Formular aus möglichst nicht direkt auf die Controls auf dem Frame durchgreifen,
sondern über Properties abkapseln.

Jetzt muss ich mal dazwischen fragen.

1. Warum nicht durchgreigen?
2. Wenn die Propertys aller enthaltenen Controls abkapseln soll, dann kann er doch auch gleich ein CustomPanel nehmen und daraus eine Komponente mit den enthaltenen Edits usw. schreiben. Das Kapseln macht er dann über einen zentralen Wrapper. Den hat er schön im Inspektor und setzt mit einem Ruck die Eigenschaften aller enthaltenen Controls (z.B. Color, Font etc.).

Gruß oki

[shmia]

Zitat von oki:

1. Warum nicht durchgreifen?

Damit man innerhalb des Frames die Freiheit hat, etwas zu ändern.
Beispiel:
Das Edit-Control mit Namen EditKanal soll in eine HistoryCombobox (neuer Name CboKanal) umgewandelt werden.
Diese Änderung könnte mehrere Änderungen am Rest der Anwendung nach sich ziehen.
Wenn man dem Frame das Property "Kanal" gibt, dann beschränken sich die Änderungen auf das Frame.
Ausserdem zeigt man so explizit, was in das Frame rein- und rausgeht.

Zitat von oki:

2. Wenn die Propertys aller enthaltenen Controls abkapseln soll, dann kann er doch auch gleich ein CustomPanel nehmen und daraus eine Komponente mit den enthaltenen Edits usw. schreiben. Das Kapseln macht er dann über einen zentralen Wrapper. Den hat er schön im Inspektor und setzt mit einem Ruck die Eigenschaften aller enthaltenen Controls (z.B. Color, Font etc.).

Im Prinzip schon.
Aber ein Frame ist leichtgewichtig; man kann schnell mal etwas ändern und darf dann auch man direkt auf die innerliegenden Controls zugreifen.

Eine Komponente ist dagegen schwergewichtig; die innerliegenden Controls sind nicht direkt erreichbar.
Wenn man z.B. die Farbe eines inneren Controls von Aussen ändern möchte, dann muss man ein neues Property einführen.
Dazu muss man das Package neu kompilieren und kann dann erst in der Anwendung das neue Property benützen.
Und dann fällt einem ein, dass das mit der Farbe doch keine so tolle Idee war und man muss den Prozess wieder durchlaufen.
Ich schätze mal, dass eine Änderung an einer Komponente 5 Mal mehr Zeit benötigt, als eine Änderung an einem Frame.