Komponenten zu labeled Komponenten "wandeln"

[Sherlock]

Ahoi,
Ich möchte gerne einen Sack voll Komponenten verschiedenster Provenienz (deren Sourcen mir vorliegen) zu "labeled" Komponenten machen.
Der naive Schritt wäre jetzt von jeder einzelnen Komponente eine abgeleitete Variante zu erzeugen, die eben um die nötigen Label-Eigenschaften erweitert wurde. Bei zwei Komponenten ist das mit gutem Willen villeicht noch abnickbar... ich möchte das aber für vielleicht 10 Komponenten tun, und es sollte auch einfach auf Neuzugänge anwendbar sein.
Jetzt dachte ich mir, das eventuell das Decorator Pattern eine Hilfe sein könnte. Ich stelle mir als Basisklasse TComponent vor, das ich eben mit einem Label "dekoriere" und somit einen TComponentDecorator baue. Ich weiss, probieren geht über studieren, aber falls einer gleich sagen kann "das wird nix" wäre das immerhin ein Schritt Richtung Zeitersparnis ;)

Sherlock

[himitsu]

Klar geht das.

Kennst du noch meine brendenden Hints?
(da wo ich mal rumgespielt hatte und den FMX-Komonenten die fehlenden Hint ersetzte)


Praktisch eine Parentkomponente welche die Labels erstellt und verwaltet.
Einem Listenproperty würden dann die Labels gepsiechert (Praktisch wie beim Popummenü)
und jedes Label besitzt dann eine Eigenschaft, über welche man die gewünschte Komponente zuweist. (TDataSource=dein Label und das TDataSet ist irgendeine Komponente)

Dann noch die Freigabeeventes registrieren.
TComponent.FreeNotification und TComponent.RemoveFreeNotification, damit die Verlinkungen und eventuell auch das Label aufgeräumt werden können, wenn du eine Komponente von der Form löschst, wo ein Label dran hängt.

Und dann noch irgendwie in die Messages der Komponenten reinhängen, um auf Resize/Move/Visible/Enable-Änderungen ranzukommen und das Label entsprechend anzupassen.


(Letztes hab ich zwar keine Ahnung wie, aber das geht bestimmt irgendwie)

[Sherlock]

Danke! Dann schau ich mir mal die brennenden Hints an...bis mir die Augen brennen ;)

Sherlock

[himitsu]

Nur ob die noch was bringen?

Die waren mal für FMX 1.0 geschrieben und bissl für 2.0 angepasst, wo fast alles umgebaut wurde.
Und inzwischen ist Delphi nochmal paar Versionen weiter. :stupid:
Und im Gegensatz zur VCL war die Ausrichtung einfacher, da man die Koordinaten relativ zur gewünschten Komponente angeben konnte, wenn man den Parent entsprechend setzt, aber die Komponente mußte nicht "innerhalb" der Parentkomponente platziert sein, was bei der VCL (Windows-Controls) aber vorgegeben ist.
Hatte es als Beispiel für die Verlinkung genannt (auch wenn es keine all zu gute Lösung war).


Als "Vorlagen" für die Verknüfungen scheinen TPopupMenu+TMenuItem(s) und in den Items dann TDataSource=>TDataSet recht gut geeignet zu sein.
(jedenfalls sollte man da wenige Probleme bekommen und von der Bedienung her wäre es praktisch ein bekanntes Muster)

Man kann natürlich auch gern schauen, wie das z.B. bei den LiveBindings gemacht wurde.

[stahli]

Ich hatte eine längere Antwort fertig, die dann aber wieder verworfen... Jetzt bin ich unsicher, was Du willst...

VCL/FMX?
Fertiges Formular und nachträglich Labes an die Controls?
Warum nicht auf klassischem Weg (also normale Labels)?
Sollen die Labels in der dfm gespeichert werden?
Sollen sie unterschiedlich ausgerichtet und dynamisch beschriftet werden?

Nevig wäre, Labels von Hand auf´s Formular zu setzen und auszurichten. Wenn es allerdings nur statische Beschriftungen sein sollen ist es vermutlich der schnellste Weg (sofern man nicht entsprechende fertige Controls mit Label hat).

Ansonsten kannst Du so etwas wie eine Groupbox bauen, nur mit der Beschriftung links und ohne Rahmen.

Einen ganz anderen Ansatz hatte meine Layout-Komponente, die Controls ausrichten und (nachträglich) beschriften konnte. Zur Laufzeit ging das perfekt, aber die IDE wollte das Konzept nicht so recht akzeptieren.

[jaenicke]

Zitat:

Zitat von stahli (Beitrag 1251093)

Nevig wäre, Labels von Hand auf´s Formular zu setzen und auszurichten. Wenn es allerdings nur statische Beschriftungen sein sollen ist es vermutlich der schnellste Weg (sofern man nicht entsprechende fertige Controls mit Label hat).

Wobei das immer neu ausrichten bei Verschiebungen bei Firemonkey ja nicht mehr nötig ist, da kann man die ja einfach an andere Komponenten antackern.

[Sherlock]

Also nur zur Klärung: Ich möchte sowas wie das Vcl.ExtCtrls.TLabeledEdit für zB ein TDateTimePicker oder auch ein TwwDBSpinEdit oder ein TMemo etc. Das soll dann die Arbeit vereinfachen, ich finde es extrem praktisch wennd as Label gleich am Edit hängt, und auch auf "Knopfdruck" neu ausgerichtet werden kann.

Himitsus Ansatz scheint mir leider nicht geeignet, ich will zur Designzeit die Labels schon sehen können.

Sherlock

[himitsu]

Du kannst sie da doch auch schon anzeigen?

Ob nun Laufzeit oder DesignTime, ist eigentlich egal.
Untereinander sind die Komponenten gleich verbunden.

Der Owner der sichtbaren Labels darf aber nicht der Form entsprechen.
Es sollte sowieso die MasterKomponente sein, bzw. die Listenkomponente darin.

Die Iteminstanzen könnte man eben wie im TPoupMenü verwalten, oder wie die Fields in einigen DataSet-Komponenten.
Und wie bei diesem komischen DevExpressMenü kann man das auch schon zur Designtime anzeigen.

Wobei du da eventuell noch nichtmal zwischen DesignTime und Runtime entscheiden mußt, wenn du nicht willst/brauchst, daß deine Labels direkt im OI "anklickbar" sein sollen. (so wie das Label im TLabeledEdit)

[Sherlock]

Ich geh ins Wochenende :)

Hier mein Versuch das per decorator pattern umzusetzen.
Das sind noch keine Komponenten, das käme später, es geht erstmal um Machbarkeit:

Delphi-Quellcode:

type
  TNxBoundLabel = class(TBoundLabel)            //* Damit wir an die protected-Innereien herankommen
  end;

  TNxLabeledControl = class(TCustomEdit)        //* Der Dekorateur für TCustomEdit
  private                                       //* TCustomEdit deshalb, weil viele Komponenten davon abgeleitet sind...Datepicker leider nicht.
    fCustomEdit: TCustomEdit;
    fEditLabel: TNxBoundLabel;
    fLabelPosition: TLabelPosition;
    fLabelSpacing: Integer;
    procedure SetLabelPosition(const Value: TLabelPosition);
    procedure SetLabelSpacing(const Value: Integer);
  protected
    procedure SetParent(AParent: TWinControl); override;
    procedure Notification(AComponent: TComponent; Operation: TOperation); override;
    procedure SetName(const Value: TComponentName); override;
    procedure CMVisiblechanged(var Message: TMessage); message CM_VISIBLECHANGED;
    procedure CMEnabledchanged(var Message: TMessage); message CM_ENABLEDCHANGED;
    procedure CMBidimodechanged(var Message: TMessage); message CM_BIDIMODECHANGED;
  public
    constructor Create(AOwner: TComponent; aCustomEdit: TCustomEdit); reintroduce;
    procedure SetBounds(ALeft: Integer; ATop: Integer; AWidth: Integer; AHeight: Integer); override;
    procedure SetupInternalLabel;
    property EditLabel: TNxBoundLabel read FEditLabel;
  published
    property LabelPosition: TLabelPosition read FLabelPosition
      write SetLabelPosition default lpAbove;
    property LabelSpacing: Integer read fLabelSpacing write SetLabelSpacing
      default 3;
  end;

  TNxEdit = class(TNxLabeledControl)    //* Das zu dekorierende Control ist in diesem einfachen Fall ein TEdit (siehe Code im Contrustor)
  private
    fNXLabeledControl: TNxLabeledControl;
  public
    constructor Create(aOwner: TComponent);
    destructor Destroy; override;
  end;

Die meisten Methoden sind im Prinzip C&P aus TCustomLabeledEdit. Worauf es IMO ankommt ist:

Delphi-Quellcode:

constructor TNxLabeledControl.Create(AOwner: TComponent; aCustomEdit: TCustomEdit);
begin
  inherited Create(AOwner);
  fCustomEdit := aCustomEdit;
  FLabelPosition := lpAbove;
  FLabelSpacing := 3;
  SetupInternalLabel;
end;

procedure TNxLabeledControl.SetupInternalLabel;
begin
  if Assigned(FEditLabel) then
    exit;
  if not Assigned(fCustomEdit) then
    exit;
  FEditLabel := TNxBoundLabel.Create(fCustomEdit);
  FEditLabel.FreeNotification(fCustomEdit);
  FEditLabel.FocusControl := fCustomEdit;
end;

Der Code für das zu labelnde Edit

Delphi-Quellcode:

constructor TNxEdit.Create(aOwner: TComponent);
begin
  inherited Create(aOwner, TEdit.Create(Self));   //* Hier steht endlich die zu verwendende Komponente
end;

destructor TNxEdit.Destroy;
begin
  fCustomEdit.Free;
  inherited;
end;

In einem ersten Test wird zwar das Edit angezeigt, nicht jedoch das Label :D Ich freue mich aber darüber das es nicht knallt ;)

Ich schau Montag wieder rein. Bis denne!

Sherlock

[Helmi]

Hallo,

ich hab mir auch mal TLabeled-Komponenten gebaut
Hab ein TLabeledComboBox, TLabeledSpinEdit, TLabeledMaskEdit und ein paar Sonder-Komponenten.

Wobei ich nicht nur ein Label drin hab, sondern 2 (pre und pro)
Also eines vor links z. B. und eines vor rechts (z. B. links für einen Infotext, rechts für eine Einheit)

Anbei mal mein TLabeledSpinEdit

eigentlich unterscheiden sich die o. g. Komponenten nur in dieser Zeile:

Delphi-Quellcode:

TLabeledSpinEdit = class(TSpinEdit)

(und natürlich der Klassennamen der functions....)

[Sherlock]

Hallo Helmi,
wunderschön. Sowas habe ich ja auch vor. Mit dem Unterschied, daß ich nicht für jede weitere gelabelte Komponente den gleichen Code kopieren möchte. Da muss es doch was von Ratioph...äh von den Freunden aus der GoF geben. Ich dachte eben an das Decorator Pattern, weil ich (eventuell zu bildlich denkend) das Label für die Dekoration eines Controls halte. Ich setze mich heute wieder ran, und schau ob ich es nicht doch noch hinbekomme. Ich will ja auch was lernen ;) ISt ja eigentlich fast fertig, es fehlt schließlich nur die Anzeige des Labels.

Sherlock

[WoGe]

Wenn es darum geht das Decorator Pattern hier zu verwenden, ist mein Ansatz wahrscheinlich falsch.
Aber waren die Frames nicht auch dazu gedacht, genau so was zu realisieren?

Ein Frame der ein TLabel und ein TxxxxEdit enthält - samt der ganzen Logik die dazu benötigt wird?

Grüße
wo

[stahli]

Falls Du es mal testen willst, hier doch mal mein Ansatz.
(Einfach die Formulargröße soweit verkleinern dass die Contros zusammengeschoben werden und mehrfach Button4 drücken.)

Es werden Rahmen- bzw. Beschriftungscontrols dynamisch hinter die eigentlichen Controls platziert, ohne dass diese in irgendeiner Weise verändert werden.

Die Umschaltung des "Beschriftungsstiles" war grundsätzlich in einem Komponenteneditor zur Designtime vorgesehen. Die Eigentliche Komponente wird in meinem Fall verkleinert, so dass sie in den Rahmen passt (und die Komponente incl. Rahmen immer den gleichen Platz in ihrem Umfeld braucht).

Im Formular werden die dynamisch erzeugten "Rahmenkomponten" nicht gespeichert, sondern nur die Regeln, die für das Ausrichten und Beschriften gelten sollen.

Zur Laufzeit klappte das alles super. Innerhalb der IDE nicht so.

Es ist also m.E. nicht ganz so einfach, das dynamisch zu lösen, ohne Controlderivate zu verwenden. Immerhin musst Du ja auch den Beschriftungstext und die Ausrichtung irgendwie im Formular speichern.

Zeig mal ein paar Screenshots, wenn Du´s fertig hast...

[Sherlock]

Ich habe das Thema begraben, da es mit dem decorator pattern nicht mit vertretbaren Aufwand umsetzbar ist. Im Prinzip liegt es an der VCL. Es wäre ein Interface für TWinControl nötig, das als Grundlage für den Decorator dienen würde. Oder aber es müsste Mehrfachvererbung in Delphi geben...auch das gibts nicht. Also hab ich es beiseite gelegt und würde es über die althergebrachte Methode machen. Dabei werde ich halt versuchen so viel code wie möglich wiederzuverwenden, aber... elegant ist anders.

Ich danke Euch für Eure Ideen! :thumb:

Sherlock

[Sir Rufo]

Bau dir doch einen Container (abgeleitet von TCustomPanel) und bestück das mit allem was du benötigst. Die Controls kannst du dann einfach da rein klatschen und gut ist.