Standard-Kompos um eigene Eigenschaften erweitern?

[schorsch]

Moin,
ich wollte mal in die Runde fragen, ob da jemand vielleicht ne Idee zu hat.

Die meisten Kompos für mein Prog nehme ich aus der Komponentenpalette - sprich: erstelle sie nicht erst zur Laufzeit. Jetzt überlege ich, ob es relativ einfach moeglich waere, allen "visible"-kompos zusaetzlich ein paar eigenschaften zu geben - sowas, wie "Tag" (zb 1 x bool, 1 x string, ein aufaehlungstyp und ein eigenes "tag") - haette da jemand ne Idee, wie das machen koennte, sodass die dann auch in den Eigenschaften einstellbar waeren, wenn man eine aufs form zieht? Hatte sowas noch nicht, deswegen, sorry, wenn die frage doof sein sollte

Tks vorab..
de schorsch

[Mathias]

Am besten vererbst du eine bestehende Komponenten und erweiterst diese dann um deine neuen Eigenschaften.
Aber für den Anfang würde ich dann diese Komponenten dynamisch im Form verwenden. Später kann man sie dann immer noch in die Komponentenpalette integrieren. Wobei ich für eigene Komponenten die dynamische Variante vorziehe.

[schorsch]

Hi nochmal,
ja, nein, genau das wollte ich ja eben nicht. Sagen wir mal ich habe rund 500 Komponenten auf einem Formular, das sehr präzise angeordnet ist. Im Prinzip dachte ich, ich lade das Prog in die IDE und "plötzlich" haben alle kompos weitere Eigenschaften, die mit Default-werten vorbelegt sind - wie gesgat, ähnlich dem Tag. Ich habe schon versucht TComponent abzuändern - da meckert aber rum, ihm würde der member fehlen. Wir reden hier von rund 1 Mio Codezeilen und 1000de kompos und forms - und das kann ich nicht einfach mal auf "dynamisch" umstellen.

Noch ne Idee?

Tks..
de Schorsch

[wp_xyz]

ich habe rund 500 Komponenten auf einem Formular

Der arme User, der sich da zurecht finden soll...

Jetzt im Ernst: Eine selbst-geschriebene Komponente MUSST du zuerst zur Laufzeit erzeugen, um sie zu testen. Wenn du eine fehlerhafte Komponente in die IDE installierst, stürzt dir wahrscheinlich die IDE ab, und dein restlicher Tag wird wahrscheinlich nicht sehr angenehm. Erst wenn alles sauber läuft, kannst du die Komponente installieren.

Bevor zu anfängst, alle möglichen Komponenten zu ändern, solltest du vielleicht etwas genauer beschreiben, was du genau machen willst. denn "- sowas, wie "Tag" (zb 1 x bool, 1 x string, ein aufaehlungstyp und ein eigenes "tag"" hat wahrscheinlich niemand verstanden. Was sollen diese zusätzlichen Properties bewirken?

[schorsch]

hmm, irgendwie...

Also: Godfahther ist doch TComponent. Und das hat .Tag und .Name IMMER. Jetzt dachte ich in meinem jugendl. Leichtsinn, dass man da einfach 1,2,3.. Eigenschaften dazubauen koennte und schwups sind die im Objektinspektor mit Standardwerten vorbelegt - und zwar bei allen kompos. natuerlich erst, wenn ich Lazarus recompiliert, etc. habe. jetzt klar, was ich meine?

aber, wie gesagt, ich frage ja nur - hab schon ne Idee, wie ich es auch anders hinbekomme.

tks..

de schorsch

[Mathias]

aber, wie gesagt, ich frage ja nur - hab schon ne Idee, wie ich es auch anders hinbekomme.

Das wird wohl besser sein. Die LCL von Lazarus zu modifizieren ist nicht unbedingt schlau.

[wp_xyz]

hmm, irgendwie...

Also: Godfahther ist doch TComponent. Und das hat .Tag und .Name IMMER. Jetzt dachte ich in meinem jugendl. Leichtsinn, dass man da einfach 1,2,3.. Eigenschaften dazubauen koennte und schwups sind die im Objektinspektor mit Standardwerten vorbelegt - und zwar bei allen kompos. natuerlich erst, wenn ich Lazarus recompiliert, etc. habe. jetzt klar, was ich meine?

Die Hierarchie von Komponenten ist wie ein Baum. Der Stamm ist TObject. Ein Ast, der abgeht, heißt TComponent, und der ästelt sich immer weiter auf in, letztendlich, TEdit, TListbox usw. Wenn du jetzt TComponent mit einer neuen Eigenschaft ausstattest, hast du von TComponent einen neuen Ast abgezweigt, bevor die anderen Komponenten abzweigen. Daher wird die neue Eigenschaft nicht an die anderen Komponenten weitervererbt.

Das was du vorhast, bedeutet, dass du in den Quelltext von TComponent eingreifst und TComponent selbst veränderst. Damit hast du die LCL verändert und auch alle Programme, die die LCL verwenden, insbesondere Lazarus. Das mag funktionieren, nur ist beim nächsten Update von Lazarus die ganze Pracht wieder verschwunden, weil die neue Eigenschaft nicht mehr in TComponent vorhanden ist. -- Dazu würde ich auf keinen Fall raten.

[Frank Ranis]

Hallo schorsch,

Du könntest auch THelper benutzen.
Damit kann man schnell mal ein paar Zusatzeigenschaften und neue Methoden einbauen.

Code: Alles auswählen

unit unit2;
 
{$mode objfpc}{$H+}
{$MODESWITCH ADVANCEDRECORDS}    // <-- nicht vergessen
 
interface
 
uses
  Classes, SysUtils, FileUtil, Forms, Controls, Graphics, Dialogs, StdCtrls;
 
type
 
  { TEditHelper }
  TEditHelper = class helper for Tedit
   // Neue Variablen für alle TEdit
   class var Tag1,Tag2:integer;
   class var int_array:array[0..9] of integer;
   // neue Methoden für alle TEdit
   Procedure setcolor(c:tcolor);
  end;
 
 
  { TForm1 }
  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    Button3: TButton;
    Button4: TButton;
    Edit1: TEdit;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
    procedure Button3Click(Sender: TObject);
    procedure Button4Click(Sender: TObject);
  private
 
  public
 
  end;
 
var
  Form1: TForm1;
 
implementation
 
{$R *.lfm}
 
{ TForm1 }
 
procedure TForm1.Button1Click(Sender: TObject);
begin
 edit1.Tag1:=10;
 edit1.Tag2:=20;
 edit1.Text:=inttostr(edit1.Tag1+edit1.Tag2);
end;
 
procedure TForm1.Button2Click(Sender: TObject);
begin
 edit1.setcolor(cllime);
end;
 
procedure TForm1.Button3Click(Sender: TObject);
begin
 edit1.setcolor(clyellow);
end;
 
procedure TForm1.Button4Click(Sender: TObject);
var i:byte;
begin
 for i:=0 to 9 do
  edit1.int_array[i]:=i;
 
 edit1.Text:='';
 for i:=0 to 9 do
  edit1.Text:=edit1.Text+inttostr(edit1.int_array[i])+' ';
end;
 
 
{ TEditHelper }
 
procedure TEditHelper.setcolor(c: tcolor);
begin
 self.Color:=c;
end;
 
end.
 

Gruß

Frank

[m.fuchs]

Die Helper helfen dem OP nicht, da er ja zusätzliche published Eigenschaften benötigt, die der Objectinspector per RTTI auslesen kann.

[Michl]

Wenn man ganz ganz ganz dringend alle Komponenten um eine Eigenschaft erweitern will, kann man das eigentlich problemlos machen, da die Sources ja vorliegen.

Sowas würde ich aber nur empfehlen, wenn man Lazarus (und FPC) per Versionskontrolle geladen hat und man diese jeweils selber übersetzt. Dann kann man einen Branch von Lazarus bzw. FPC erstellen und dort die eigenen Erweiterungen vornehmen (hilfsweise könnte man einen Patch für die eigenen Änderung erstellen und jedes mal bei der eigenen lokalen Kopie einspielen, wenn man FPC/Lazarus updatet).

Evtl. wird ein zusätzliches Property nur bis Vorfahr bis TWinControl, TControl oder TLCLComponent benötigt, dann reichte es, wenn man (einen Branch von) Lazarus patcht. Wird ein zusätzliches Property bei TComponent benötigt, müsste die RTL neu übersetzt, also muss (ein Branch von) FPC gepatcht werden.

[Frank Ranis]

Hallo ,

noch einen drauf .

Im Wahn habe ich folgendes probiert.

Anstatt nur eine Komponente (z.B. TEdit oder TButton) mit den neuen Eigenschaften per Helper auszurüsten , bin ich an den Vorfahren

dieser Komponenten rann gegangen .

Das TWinControl.

type

{ TWinControlHelper }
TWinControlHelper = class helper for TWinControl
// Neue Variablen für alle Nachfahren von TWinControl
class var Tag1,Tag2:integer;
class var int_array:array[0..9] of integer;
// neue Methoden für alle Nachfahren von TWinControl
procedure setheight(v:integer);
end;

implementation

// neue Methode setheight
procedure TWinControlHelper.setheight(v: integer);
begin
self.Height:=v;
end;

Alle Nachfahren von TWinControl haben nun die neuen Eigenschaften und Methoden übernommen.

Kann nun schreiben.

Form1.tag1:=10;
Form1.tag2:=20;

oder

Button1.Tag1:=30;

auch die neue Methode

TWinControlHelper.setheight(v: integer);

kann ich nun für alle Komponenten benutzen , die von TWinControl abstammen und eine Größenänderung zulassen.

Form1.setheight(100);
Panel1.setheight(30);
Button1.setheight(20);

Ist das genial , Lazarus ist genial .
Da braucht man doch nun wirklich nicht am LAZ selber rumpfuschen .

Muß das mit der Verfügbarkeit der neuen Eigenschaften im Objektinspektor wirklich sein ?

Gruß

Frank

[mse]

Code: Alles auswählen

 
class var Tag1,Tag2:integer;
class var int_array:array[0..9] of integer;
 

sind globale Variablen und für alle Instanzen gemeinsam.

[Frank Ranis]

Hallo mse,

Code: Alles auswählen

 
class var Tag1,Tag2:integer;
class var int_array:array[0..9] of integer;
 

sind globale Variablen und für alle Instanzen gemeinsam.

Ja schitt , Du hast recht , ganze Idee dahin.
Auch wenn man sich nur auf die direckte Komponente beschränkt (z.B. TEdit) sind die Variablen nur global in TEdit vorhanden.

Gib es eventuell einen Trick ?

Gruß

Frank

[mse]

Gib es eventuell einen Trick ?

Nein, class helper sind lediglich "syntactic sugar". Man kann das Gleiche auch mit Typenkonversion erreichen.

[Mathias]

Nein, class helper sind lediglich "syntactic sugar". Man kann das Gleiche auch mit Typenkonversion erreichen.

Auf jedenfalls ist ein Typen Helper eine geniale Sache. Vor allem auch, wen man selbst einen Datentyp baut. Ich habe für OpenGL einen Vektordatentyp, den konnte ich somit sehr einfach um Methoden erweitern. So wie FPC es selbst zB. beim String nutzt.