Wann ist die Zeit für eine eigene VCL-Komponente gekommen?

[stahli]

@sx2008
Ich kann Dir nicht ganz folgen. Von Geschäftslogik in GUI-Controls hat bisher niemand gesprochen - wenngleich die Ablehnung dergleichen völlig richtig ist.
Wenn passende Komponenten verfügbar sind wird man die natürlich nicht nochmal neu erfinden.
Andernfalls kann man sie einmal erststellen und immer wieder verwenden.
Es macht letztlich keinen Unterschied ob die TLEDArray irgendwoher bezogen oder selbst entwickelt wird.

GUI-Controls sollten ihrerseits so allgemein gehalten sein, dass sie nicht an eine bestimmte Geschäftslogik-Version gebunden sind.
Wenn Du davon ausgehst, dass die Controls ständig mitwachsen und Du auch alte Versionen benutzen willst, dann würde ich die Controls generell dynamisch erzeugen und in der Versionsverwaltung aufnehmen.


@SchönerGünther
Ich denke, Du kannst hier Interfaces (im Sinne von Delphi-Interfaces) erst mal außen vor lassen.
Ob Du Deinem Control ein Objekt oder ein Interface übergibst ist im Grunde egal. Wenn Du eh nur genau eine Datenklasse für Dein sichtbares Control zuweist, dann kannst Du auch einfach das Objekt übergeben.
Interfaces braucht man, wenn man unterschiedliche Klassen mit definierten Schnittstellen benutzen will oder mit DLL´s kommuniziert. (würde ich jetzt so zusammenfassen)

[Furtbichler]

Ich persönlich halte nicht viel von selbstgebauten Spezialkomponenten, außer, sie sind allgemeingültig. Ich persönlich habe meine Komponentensammlungen und mehr kommt mir nicht dazu.

Im Endeffekt haben wir es hier doch 'nur' mit einer Darstellung zu tun, die selbst keine Funktionalität beinhaltet, oder?

Die Lösung mit dem DrawGrid ist doch ok, findest Du nicht? Großartig anders wird eine eigene Komponente auch nicht aussehen.

Was Du hier -und das haben ja schon alle gesagt- betreiben musst, ist eher die Trennung von Darstellung und Logik. Nicht, das man das machen müsste, aber wenn Du das machst (jeder macht das, was er am Besten kann), dann wird das wirklich sauber und -wer weiss- vielleicht kannst Du dann deine DrawGrid-Geschichte (die ich in einen Frame packen würde, wie schon vorgeschlagen) nochmal verwenden.

[Sir Rufo]

Also wenn ich mir deine Komponente so ansehe, dann würde ich die mal wie folgt beschreiben

Delphi-Quellcode:

unit MyControl;

TMyControlItem = class( ... )
  property Caption : string;
  property Color : TColor;
end;

TMyControl = class( ... )
published
  property BorderColor : TColor;
  property BorderWidth : Integer;
  property ItemCount : Integer;
  property Items[Index : Integer] : TMyControlItem;
end;

Dein DatenObjekt sieht nun wohl irgendwie so aus:

Delphi-Quellcode:

unit Data;

TDataChild = class
  property On : Boolean;
end;

TData = class
  // Sigalisierung bei Änderungen über einen Event
  property OnChange : TNotifyEvent;
  // oder eine Event-Liste ;)
  procedure AddOnChange( ANotify : TNotifyEvent );
  procedure RemOnChange( ANotify : TNotifyEvent );

  property On : Boolean;
  property ChildCount : Integer;
  property Childs[Index : Integer] : TDataChild;
end;

Für die Visualisierung baust du dir jetzt einfach einen abstrakten Presenter zwischen dem Objekt und irgendeinem Control

Delphi-Quellcode:

unit DataPresenter;

uses
  Data;

TDataPresenter = class abstract
  // Diese Methode soll aufgerufen werden, wenn Data sich ändert
  procedure DataChange( Sender : TObject ); virtual; abstract;
  property Data : TData;
end;

und konkret

Delphi-Quellcode:

unit MyControlDataPresenter;

uses
  DataPresenter, 
  MyControl;

TMyControlDataPresenter = class( TDataPresenter )
  constructor Create( AControl : TMyControl );
  procedure DataChange( Sender : TObject ); override;
  property OnColor : TColor;
  property OffColor : TColor;
  property NilColor : TColor;
end;

P.S. Wenn du Spring4D im Einsatz hast, da gibt es Event<T> der einem einen MultiCast-Event auf die Schnelle hinzaubert

P.S.S. Im Anhang mal eine kleine Demo nach diesem Muster und der Präsentation in einem StringGrid