text: Standard-Kompos um eigene Eigenschaften erweitern? : Komponenten und Packages • Deutsches Lazarusforum
  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
  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.
  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.
  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?
  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.
  Die Helper helfen dem OP nicht, da er ja zusätzliche published Eigenschaften benötigt, die der Objectinspector per RTTI auslesen kann.
  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.
  Anstatt nur eine Komponente (z.B. TEdit oder TButton) mit den neuen Eigenschaften per Helper auszurüsten , bin ich an den Vorfahren
  kann ich nun für alle Komponenten benutzen , die von TWinControl abstammen und eine Größenänderung zulassen.
  Auch wenn man sich nur auf die direckte Komponente beschränkt (z.B. TEdit) sind die Variablen nur global in TEdit vorhanden.
  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.