![]() |
Abgeleitete Formularklasse verwenden
Hallo,
ich habe von der Klasse TForm meine eigene Klasse TfdForm abgeleitet, in die ich etwas zusätzliche Funktionalität packen will, und von dieser dann in der Folge meine Formulare ableiten. Mir ist aber nicht klar, wie ich den Formulardesigner dazu bringe, als Basisformularklasse für eine Unit die Klasse TfdForm statt TForm zu akzeptieren. |
Re: Abgeleitete Formularklasse verwenden
Hallo idefix2,
du kannst dafür die Objektablage benutzen. Bis bald Chemiker |
Re: Abgeleitete Formularklasse verwenden
Du kannst auch einfach im Quellcode bei der Klassendeklaration TForm in den Namen deiner Klasse ändern. So hab ich es zumindest mal gemacht und es hat geklappt.
|
Re: Abgeleitete Formularklasse verwenden
Irgendwo ist mir etwas nicht klar.
Delphi-Quellcode:
Ich möchte jedes Formular, das ich verwende, standardmäßig mit einer Toolbar (und in der Folge noch mit einigem anderen) ausstatten.
unit fdFormular;
interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, ComCTrls ; type TfdForm = class(TForm) MainToolbar: TToolBar; end; var Form1: TfdForm; implementation {$R *.dfm} end. So wie im oben angeführten Code geht es jedenfalls nicht, die Unit kompiliert gar nicht, offenbar weil das Formular im Formulardesigner vom Typ TForm und nicht zu meinem Form1 passt. |
Re: Abgeleitete Formularklasse verwenden
Wie hast du es denn jetzt gemacht? In diesem Fall musst du die Objektablage benutzen. Bei "zusätzlicher Funktionalität" dachte ich eher an reinen Code, wo es auch mit dem kleinen Trick geklappt hätte.
|
Re: Abgeleitete Formularklasse verwenden
Wie wäre es, wenn du die Toolbar und so in einen Class-Helper implementierst. Dann interessiert das den Designer nicht.
Nachteil ist: Nur zur Laufzeit sichtbar Komponenten müssen selbst erzeugt werden. |
Re: Abgeleitete Formularklasse verwenden
Hallo BenjaminH,
dafür sind die Class-Helper aber nicht gemacht, sonder um fehlende Funktionalität in Klassen zu erweitern. Meiner Meinung ist dafür die Objektablage, oder ein Frame, oder ein Komponenten-Template geeignet je nach Anforderung. In diesem Fall würde ich die Objektablage bevorzugen. Bis bald Chemiker |
Re: Abgeleitete Formularklasse verwenden
Jetzt hab ich mich mit der Objektablage ein bisschen gespielt.
Unit erstellen, eine Toolbox und einen Label ins Formular setzen und eine oncreate-Behandlungsroutine erstellen. Dann im Formulardesigner ein Rechtslick auf das Formular - Der Objektablage hinzufügen - und schon taucht meine Vorlage in der Toolpalette auf. So weit, so gut. Leider ist das Ganze statisch. Laut Delphi Dokumentation sollte ich so eine Vorlage aus der Objektablage für mein Projekt "kopieren", "erben" oder "gemeinsam behandeln" können, wie das geht, konnte ich aber nicht herauslesen - mir gelingt nur das Kopieren durch Doppelklick auf das Objekt in der Toolpalette. Damit ist mir aber nicht geholfen, weil ich die Funktionalität dieser Formulare ja auch in Zukunft erweitern oder verändern möchte, und diese Ändererungen dann automatisch in allen Units übernommen werden sollen. Der Tipp mit dem Class Helper wäre eine Notlösung, mit der ich eventuell leben könnte - wenn es keine andere Möglichkeit gibt, werde ich es so machen. Aber eigentlich würde ich schon lieber zur Designzeit alles sehen, was sich auf dem Formular so tut, vor allem weil die Reihenfolge der Erstellung der Komponenten die Anzeige beeinflusst (in Verbindung mit der align Eigenschaft) und die fixen Komponenten deshalb besser zuerst erstellt werden sollten. Der springende Punkt ist: Wie kann ich den Formulardesigner davon überzeugen, dass meine abgeleiteten Formulare keine bösen sind und dass er sie durchaus an Stelle von TForm akzeptieren kann? |
Re: Abgeleitete Formularklasse verwenden
|
Re: Abgeleitete Formularklasse verwenden
Danke, das wars. Wirklich fein, dass das so funktioniert.
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 20:22 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz