Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   GUI-Design mit VCL / FireMonkey / Common Controls (https://www.delphipraxis.net/18-gui-design-mit-vcl-firemonkey-common-controls/)
-   -   Delphi Eigenen Fenstertyp erstellen/registrieren? (https://www.delphipraxis.net/180298-eigenen-fenstertyp-erstellen-registrieren.html)

himitsu 8. Mai 2014 18:56


Eigenen Fenstertyp erstellen/registrieren?
 
Halli Hallo.

Wie kann ich denn nun eigentlich einen eigenen Fenstertyp im Delphi registrieren?
> Nachfahr eines TDataModul, bzw. einer TForm.

Das mit der Objektablage kenn ich, aber das ist ja nicht benutzbar.


Es sollen einfach nur weitere Funktionen (Property und Co.) zu den Basisklassen hinzugefügt werden.
Und diese sollen auch im Objektinspektor konfigurierbar sein.
(irgendwie sollte es dann auch noch möglich, daß man irgendwie bestimmt, welche Komponenten auf der Form/Datenmodul drauf dürfen, bzw, Welche nicht)


Der Formeditor kommt mit Nachfahren von TDataModul garnicht klar und stellt dann z.B. alles so dar, als sei es von TForm abgeleitet, inkl. der falschen Property im OI. (wenn man einfach ein TDataModule erstellt und dann im Editor den Vorfahren manuell anpasst und auch beim Weg über die Objektablage geht es nicht)
Bei einer Form stört es so zwar nicht direkt, aber dennoch fehlen im OI die eigenen Property.

Oder der Formeditor meint nur noch "Fehler beim Erzeugen von Formular: Vorfahr für '...' nicht gefunden.", beim Laden der Unit.

Union 8. Mai 2014 19:56

AW: Eigenen Fenstertyp erstellen/registrieren?
 
Vielleicht object statt inherited im dfm? Schau mal was Jeroen dazu schreibt.

himitsu 8. Mai 2014 20:09

AW: Eigenen Fenstertyp erstellen/registrieren?
 
Nee, mit inherited würde es zwar vererbt, aber der OI kennt dennoch keines der Properties. :cry:

Diese Art der Vererbung ist leider nur benutzbar, für Komponenten, welche drauf liegen und da gibt es nichts.


Ach ja, das "Vorfahr nicht gefunden" kommt, wenn es zu der Basisklasse keine DFM gibt.

D-User 8. Mai 2014 20:38

AW: Eigenen Fenstertyp erstellen/registrieren?
 
Bzgl TDatamodul ( nicht TForm ) mein Wissensstand:
das ist in Bug, in D7 hatte das noch funktioniert,
in D2010 nicht mehr. Hatte ich reklamiert, gab auch andere in QC
die das Problem hatten.
Irgendwie schien das nicht dringend genug, ich fands extrem ärgerlich.

Ich fänd vererbbare DMs schon sehr praktisch (waren sie auch in D7)hatte mir da schon ein
recht weit entwickeltes Basismodul zusammengebastelt das ich dann
leider umbauen musste.

Habe das für mich so gelöst, dass ich die Funktionalität in
Komponenten ausgelagert habe.

Vllt können ja auch ein paar Leute auf QC Druck machen,
vererbbare DMs wären mMn designmäßig schon sehr angebracht.

Wie es jetzt damit in ganz aktuellen D's aussieht weiss ich nicht,
wäre interessant zu erfahren.

Die Pluimers-Lösung ist mMn halt eine Spezial-Lösung, kein echter
Ersatz für ein vererbbares DM.



>Es sollen einfach nur weitere Funktionen (Property und Co.) zu den
>Basisklassen hinzugefügt werden.
>Und diese sollen auch im Objektinspektor konfigurierbar sein.

Das wäre wohl mit Komponenten gegeben.

PS:
den Titel "Eigenen Fenstertyp erstellen/registrieren"
find ich ein bisschen verwirrend, ich denk da an z.B. Windows-Fenstertype mit selbstgemalter Titelbar etc, wie ja in JVCL "angedacht" wurde/wird

himitsu 8. Mai 2014 21:09

AW: Eigenen Fenstertyp erstellen/registrieren?
 
Ja, die Idee, das in eine Komponente auszulagern, hatte ich auch schon, aber als "richtiges" Modul fänd ich es dennoch besser.

Ich brauch praktisch 2 Typen (DatenModul und Fenster), welche z.B. wie TService als Grundlage dienen.


[edit]
Vielleicht hab ich was gefunden, aber es ist wie immer ....... nix Genaues weiß man nicht. :wall:
http://docwiki.embarcadero.com/Libra...stomModuleProc

In der DPR speichert die IDE doch den KlassenNamen des Vorfahren, als Kommentar hinter der Unit.
Das Selbe fand dann nochmal, wo es in die DPROJ übernommen wurde, denn es steht auch im OI, wenn man in der Projektverwaltung die Unit anwählt.
In der DPROJ danach gesucht, entdeckte ich es in einem <DesignClass>-Node, das dann nach einer Suchen den VCL-Quellcodes zur OH/Google führte, in der Hoffnung was rauszufinden.

[edit2]
Zitat:

Ein benutzerdefiniertes Modul ermöglicht, dass von anderen Klassen als TForm abgeleitete Container im Formular-Designer erstellt und bearbeitet werden können. Das ist für andere Formulare, wie Container (z.B. Report-Designer), oder für spezialisierte Formulare (z.B. ActiveForm) oder für generische Komponenten-Container (z.B. TDataModule) nützlich.

himitsu 8. Mai 2014 23:34

AW: Eigenen Fenstertyp erstellen/registrieren?
 
Juhuu, es funktioniert. :cheer:

Hab die kommentierte Dekumentation im Quellcode entdeckt und angewendet.

QuickAndDirty 9. Mai 2014 14:36

AW: Eigenen Fenstertyp erstellen/registrieren?
 
Wo?
Ich wollte mal einen weiteren Anwendungstyp registrieren, hab das nicht gefunden.
Das Template sollte bereitstellen das ein laufen des Projekts als Dienst und als Anwendung möglich ist.
Bisher muss ich das immer per Hand codieren...

Sherlock 9. Mai 2014 15:13

AW: Eigenen Fenstertyp erstellen/registrieren?
 
Kannst Du das als Beispiel hier näher erläutern, Himitsu?
Weil das klingt eigentlich total praktisch.

Sherlock

himitsu 9. Mai 2014 15:58

AW: Eigenen Fenstertyp erstellen/registrieren?
 
Liste der Anhänge anzeigen (Anzahl: 1)
Der Witz dabei ist, daß ich mir grade daraus ein Henne-Ei-Problem bastle. :lol:

(mit Hilfe dieses Dings entsteht ein Helper, um nochmal sowas zu erstellen,
was "nett" werden wird, daß die OTA die Interfaceinstanz selber erstellt und mir keine Möglichkeit gibt, da einen Parameter mitzugeben. :wall:
Aber zum Glück hilft mir die RTTI beim Hacken der Klasse, wenn das so funktioniert, wie ich es erhoffe.)

Delphi-Quellcode:
uses
  DesignIntf;

type
  TMyCustomModule = class(TBaseCustomModule, ICustomModule)
    constructor Create(Root: TComponent; const Designer: IDesigner); override;
    class function DesignClass: TComponentClass; override;

    function GetAttributes: TCustomModuleAttributes;

    function GetVerbCount: Integer;
    function GetVerb   (Index: Integer): string;
    procedure PrepareItem(Index: Integer; const Item: IMenuItem);
    procedure ExecuteVerb(Index: Integer);

    procedure Saving;
    procedure ValidateComponent(Component: TComponent);
    function ValidateComponentClass(ComponentClass: TComponentClass): Boolean;
    function Nestable: Boolean;
  end;

  TMyDataModule = class(TDataModule)
  private
    FMyProp: Integer;
  published
    property MyProp: Integer read FMyProp write FMyProp;
  end;

procedure register;
begin
  RegisterCustomModuleProc(0, TMyDataModule, TMyCustomModule);
end;

constructor TMyDataModule.TMyCustomModule.Create(Root: TComponent; const Designer: IDesigner);
begin
  inherited;
end;

class function TMyDataModule.TMyCustomModule.DesignClass: TComponentClass;
begin
  Result := TMyDataModule;
end;

procedure TMyDataModule.TMyCustomModule.ExecuteVerb(Index: Integer);
begin
  case Index of
    0: ShowMessage('Execute: MyMenuItem');
  end;
end;

function TMyDataModule.TMyCustomModule.GetAttributes: TCustomModuleAttributes;
begin
  Result := [];
end;

function TMyDataModule.TMyCustomModule.GetVerb(Index: Integer): string;
begin
  case Index of
    0:  Result := 'MyMenuItem';
    else Result := '';
  end;
end;

function TMyDataModule.TMyCustomModule.GetVerbCount: Integer;
begin
  Result := 1;
end;

function TMyDataModule.TMyCustomModule.Nestable: Boolean;
begin
  Result := False;
end;

procedure TMyDataModule.TMyCustomModule.PrepareItem(Index: Integer; const Item: IMenuItem);
begin
  case Index of
    0: Item.Checked := True;
  end;
end;

procedure TMyDataModule.TMyCustomModule.Saving;
begin
end;

procedure TMyDataModule.TMyCustomModule.ValidateComponent(Component: TComponent);
begin
end;

function TMyDataModule.TMyCustomModule.ValidateComponentClass(ComponentClass: TComponentClass): Boolean;
begin
  Result := True;
end;


Alle Zeitangaben in WEZ +1. Es ist jetzt 16:16 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz