Frames und Vererbung

[Jens Schumann]

Hallo,
ich habe heute mit D7 Pro ein neues Projekt angefangen. Die Oberfläche möchte ich mit Frames realisieren. Weil ich die Konstruktorsignatur erweitern möchte habe ich einen zusätzlich Konstruktor eingefügt. TFrameBase ist der Vorfahre aller Frames.

Delphi-Quellcode:

unit tpm_base_frame;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, tpm_SystemDataprovider_impl, StdCtrls;

type
  TFrameBaseClass = class of TFrameBase;

  TFrameBase = class(TFrame)
  private
    { Private-Deklarationen }
    FActionIndex           : Integer;
    FSystemDataprovider    : TSystemDataprovider;
  protected
    property ActionIndex        : Integer read FActionIndex;
    property SystemDataprovider : TSystemDataprovider read FSystemDataprovider;
  public
    { Public-Deklarationen }
    constructor CreateNew(AOwner: TComponent; ActionIndex : Integer; SystemDataprovider : TSystemDataprovider); virtual;
  end;

implementation

{$R *.dfm}

{ TFrameBase }

constructor TFrameBase.CreateNew(AOwner: TComponent; ActionIndex: Integer;  SystemDataprovider: TSystemDataprovider);
begin
  inherited Create(AOwner);
  FActionIndex:=ActionIndex;
  FSystemDataprovider:=SystemDataprovider;
end;

end.

Jetzt habe einen Nachfahren erzeugt

Delphi-Quellcode:

unit tpm_stammdaten_frame;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, 
  Dialogs, tpm_base_frame;

type
  TFrameStammdaten = class(TFrameBase)
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
  end;

implementation

{$R *.dfm}

end.

Bis jetzt habe Delphi noch nicht neu gestartet! Alles läuft einwandfrei.
Nach dem ich Delphi geschlossen habe (ohne irgendwelche Fehlermeldungen) und anschließend wieder geöffnet habe erhalten ich beim Laden (also beim Start von Delphi) des Frames TFrameStammdaten folgende Fehlermeldung:

Fehler beim Lesen von FrameStammdaten.TabOrder:
Eigenschaft TabOrder existiert micht. Fehler ignorieren
und fortfahren usw.

Wenn ich den Fehler ignoriere siehtder Frame TFrameStammdaten aus wie ein Formualr und im OI erscheinen auch fast alle Eigenschaften und Ereignisse eines TForm.

Ich bin völlig ratlos. Woran kann das liegen?
Ich habe schon auf den Borlandseiten gesucht und im CodeCentral ein Beispiel gefunden. Dort machen die es aber genauso wie ich.

[EDIT]Ich habe mal ein minimales Beispiel angehängt [/EDIT]

[tomsel]

das passiert, wenn die Eigenschaft "Name" des Frames nicht mit dem Typbezeichner in der Deklaration übereinstimmt (Typbezeichner muß 'T'+Name sein).

Falls dies der Fall ist: Typdeklaration gleich 'T' + <jetziger_Name_des_Frame> setzen ('TFrame1' o.ä.), anschließend Frame in 'FrameStammdaten' bzw. 'FrameBase' umbenennen, der Typbezeichner wird dabei automatisch angepasst.

Nachtrag: du könntest einfach auch die *.DFM - Datei bearbeiten und dort die Name-Eigenschaft ändern.

[Jens Schumann]

Zitat:

Zitat von tomsel

das passiert, wenn die Eigenschaft "Name" des Frames nicht mit dem Typbezeichner in der Deklaration übereinstimmt (Typbezeichner muß 'T'+Name sein).

Falls dies der Fall ist: Typdeklaration gleich 'T' + <jetziger_Name_des_Frame> setzen ('TFrame1' o.ä.), anschließend Frame in 'FrameStammdaten' bzw. 'FrameBase' umbenennen, der Typbezeichner wird dabei automatisch angepasst.

Nachtrag: du könntest einfach auch die *.DFM - Datei bearbeiten und dort die Name-Eigenschaft ändern.

Vielen Dank, da komme ich aber nicht ganz mit. Die Eigenschaft Name von TFrameStammdaten war und ist FrameStammdaten.
Bei TFrameBase ist es analog.

[tomsel]

o.k., dann gibt es für diesen Fehler wohl mindestens noch eine zweite mögliche Ursache. Die kenn' ich aber leider nicht.

[omata]

Moin,

ja diesen Fehler hatte ich auch mal.

Deklariere einfach in deiner neuen Oberklasse folgendes, dann hast du keine Probleme mehr...

Delphi-Quellcode:

  :
  TFrameBase = class(TFrame)
  private
    _OldCreateOrder:boolean;
    _PixelsPerInch:integer;
    _TextHeight:integer;
  published
    property OldCreateOrder:boolean read _OldCreateOrder write _OldCreateOrder;
    property PixelsPerInch:integer read _PixelsPerInch write _PixelsPerInch;
    property TextHeight:integer read _TextHeight write _TextHeight;
  :

MfG
Thorsten

[Jens Schumann]

Hallo omata,
vielen Dank. Damit ist der Fehler beim Öffnen des Projektes

Zitat:

Fehler beim Lesen von FrameStammdaten.TabOrder:
Eigenschaft TabOrder existiert micht. Fehler ignorieren
und fortfahren usw.

leider nicht verschwunden.

[omata]

Hallo Jens,

dein Fehler hörte sich an, wie meiner. Das scheint aber doch anders zu sein.
Ich habe mir mal dein Beispiel angesehen.

Und da geht es auch ohne irgendwelchen Zusatzcode.

Also ich habe folgendes gemacht...

1. Projekt geöffnet.
2. Die beiden Fehlermeldungen mit Ignorieren bestätigt
3. Unit3 geöffnet
4. Unit3 aus der linken oberen Ecke ziehen (irgendwo anders hin)
4. Unit1 auch verschieben (minimal, damit Speichern möglich wird)
5. Projekt speichern, Fehlermeldung mit ja bestätigen

fertig.


MfG
Thorsten

[Hansa]

Zitat:

Zitat von omata

2. Die beiden Fehlermeldungen mit Ignorieren bestätigt

Und dann beten ? :mrgreen: Ich glaube nicht, daß Jens so was will.

Aber egal. Es geht mir hierdrum :

Zitat:

Zitat von Jens Schumann

ich habe heute mit D7 Pro ein neues Projekt angefangen. Die Oberfläche möchte ich mit Frames realisieren.

Unter Oberfläche ist wohl die Benutzeroberfläche gemeint ? Und die soll einheitlich und vererbbar sein ? Falls ja : So was schiebt man ins Repository, läßt Delphi die nötigen Deklarationen automatisch machen, agiert von da aus und dann kommen keine Fehlermeldungen. Mit Frames hat das dann eben nichts mehr zu tun. Wozu sollen die überhaupt gut sein ? :gruebel:

[omata]

Es geht hier nicht um beten. Delphi hat sich irgendwie verschluckt, das bedeutet ich versuche nur einen sinnvollen Weg vorzugeben, mit dem man den Code wieder zum Laufen bekommt.
Dazu gehört eben auch mal das Delphi da erst wieder manipulieren darf, wenn der User einen sinnvollen Weg vorgegeben hat. Und dazu gehört dann auch mal, dass man etwas ignoriert, weil man weiss was man tut.
Mir geht es hier um Problemlösungen, deshalb die nachvollziebaren Schritte, wie das Projekt zu retten ist (auch wenn es nur ein leeres Dummy-Projekt ist)

Hansa, wenn du keinen Sinn in Frames siehst, dann tust du mir leid. Frames sind einfach nur genial. Sie erhöhen die Übersichtlichkeit von Programmen ungemein. So kann man komplizierte Oberflächen aus kleinen Einzelunits zusammenbauen. Die Einzelunit sind dabei kleiner und dadurch erhöht sich die Programmübersichtlichkeit.

Und was ist so schlimm an vererbaren Oberflächenelementen?
Stell dir doch mal vor, die Funktionalität in deiner Oberfläche besteht aus vielen immer wieder ähnlichen Funktionen. Dann ist die Vererbung doch sehr interessant, um nicht immer das Rad neu zuerfinden. Also, wenn man etwas weiterdenkt kommen einem schon sinnvolle Ideen für Frames und Vererbung. Man kann damit natürlich auch viel Unsinn machen, aber das gilt wohl für viele Dinge. Man kann natürlich auch auf Frames verzichten und sich das Leben selber schwer machen.

[Hansa]

Omata : Wiederholung. 8) hierum geht es mir :

Zitat:

Zitat von Hansa

Aber egal. Es geht mir hierdrum :

Zitat:

Zitat von Jens Schumann

ich habe heute mit D7 Pro ein neues Projekt angefangen. Die Oberfläche möchte ich mit Frames realisieren.

Unter Oberfläche ist wohl die Benutzeroberfläche gemeint ? :gruebel:

Geht es um was komplett anderes, dann schlagt euch eben die Frames um die Ohren, aber ohne mich. :mrgreen: Ich brauche sie jedenfalls nicht und wollte eine Alternative aufzeigen. Zumindest für die Benutzeroberfläche : geht es also um folgendes : immer gleiche Tastenbedeutungen und Mausereignisse. Dimensionen, Farben, Schriftgrößen, Koordinaten usw. der Forms und der Controls darauf festlegen (auch daß überhaupt die richtigen da sind). Diese notfalls anpassen oder neu hinzunehmen und sie vererben oder eben nicht. Ist das die Frage, dann geht das wie beschrieben. Und zwar ohne Fehlermeldungen, weil auch die DFMs und andere Dateien davon betroffen sind und Delphi das schon richtig macht. Das bedeutet auch die Vorgabe INHERITED, die dann so einfach nicht mehr vergessen werden kann.

[sh17]

Das Problem liegt in den DFM-Dateien.

Für Deine Basisklasse hast Du eine DFM.Datei und für die abgeleitete auch. Das geht nicht. woher soll die klasse wissen, welche DFM sie nehmen soll?

Lösung:

Deine Basisklasse nur von TFrame ableiten. Die Ressource {$R *.dfm} löschen.

In Deiner richtigen Klasse TMyFrame kassnt Du dann die Elemente auf das Frame packen.

[Jens Schumann]

Zitat:

Zitat von omata

Hallo Jens,
Also ich habe folgendes gemacht...

1. Projekt geöffnet.
2. Die beiden Fehlermeldungen mit Ignorieren bestätigt
3. Unit3 geöffnet
4. Unit3 aus der linken oberen Ecke ziehen (irgendwo anders hin)
4. Unit1 auch verschieben (minimal, damit Speichern möglich wird)
5. Projekt speichern, Fehlermeldung mit ja bestätigen

fertig.

Ich weiss nicht wie in unit3 oder unit1 verschieben soll. Ich habe die Fehlermeldung ignoriert und ein Leezeichen hinzugefügt damit
ich das Projekt speichern kann. -> Kein Erfolg

Zitat:

Zitat von sh17

Das Problem liegt in den DFM-Dateien.

Für Deine Basisklasse hast Du eine DFM.Datei und für die abgeleitete auch. Das geht nicht. woher soll die klasse wissen, welche DFM sie nehmen soll?

Lösung:

Deine Basisklasse nur von TFrame ableiten. Die Ressource {$R *.dfm} löschen.

In Deiner richtigen Klasse TMyFrame kassnt Du dann die Elemente auf das Frame packen.

Ich habe die {$R *.dfm} in der unit für die Basisklasse gelöscht. -> Kein Erfolg.

Wie omata schon richtig bemerkt hat sind Frame gerade zu genial um Benutzeroberflächen zu realisieren. Das mache ich auch schon einige Zeit. Jede Oberflächenmaske bekommt Ihren eigenen Frame. Alle Frames haben Gemeinsamkeiten, die ich der Vergangenheit in jedem einzelnen Frame wiederholt habe. Dadurch ist natürlich eine Redundanz entstanden, die schlecht zu warten ist. Jetzt wollte ich mir die Mechanismen der OOP zu nutze machen und eine Basisklasse für die Gemeinsamkeiten verwenden. Leider hat hier D7 (D5 auch) scheinbar einen Bug.

[sh17]

Zitat:

Kein Erfolg.

Was passiert denn da?

In der Basisklasse dürfen dann natürlich keine Controls enthalten sein.

[Jens Schumann]

Zitat:

Zitat von sh17

Zitat:

Kein Erfolg.

In der Basisklasse dürfen dann natürlich keine Controls enthalten sein.

Hallo ,
in der Basisklasse sind keine Controls enthalten. Ist auch nicht nötig.
Es kommt der gleiche Fehler wie oben beschrieben.

[sh17]

hab noch mal Dein Beispiel beguckt. Das Problem liegt bei der Deklaration in Form1 (Warum genau das so ist, weiß ich auch nicht)

Du musst das Frame in einem eigenen privat-Bereich deklarieren und im Create des Forms von Hand das Frame erzeugen. Dann sollte es gehen.

[sh17]

achso, und in Deinem Beispiel scheinst Du TFrameNachfahre mal aus einem TForm in ein TFrameBase umgewandelt zu haben. Du musst ein neues Frame erstellen und dann die Elternklsase TFrame in TFrameBase abändern

EDIT: damit dürfte sich meiner vorheriger Beitrag erledigt haben

[Jens Schumann]

Zitat:

Zitat von sh17

hab noch mal Dein Beispiel beguckt. Das Problem liegt bei der Deklaration in Form1 (Warum genau das so ist, weiß ich auch nicht)

Du musst das Frame in einem eigenen privat-Bereich deklarieren und im Create des Forms von Hand das Frame erzeugen. Dann sollte es gehen.

Hmmm Hmmm Hmmm. Das Beispiel enthält zwar zwei Frames aber keiner von beiden wird verwendet. Trotzdem kommt der Fehler.
Der Fehler kommt wenn ich das Projekt öffne. Nicht wenn ich das Projekt starte!
Könntest Du bitte mein Beispiel so verändern das es funktioniert?

[Jens Schumann]

Zitat:

Zitat von sh17

achso, und in Deinem Beispiel scheinst Du TFrameNachfahre mal aus einem TForm in ein TFrameBase umgewandelt zu haben. Du musst ein neues Frame erstellen und dann die Elternklsase TFrame in TFrameBase abändern

EDIT: damit dürfte sich meiner vorheriger Beitrag erledigt haben

Natürlich habe ich nicht aus einem TForm einen TFrame gebastelt. TFrameNachfahre ist von Anfang an ein TFrame gewesen. Wenn ich das Projekt wieder öffne kommt der Fehler, dass die Eigenschaft TabOrder nicht gefunden wird. Wenn ich den Fehler ignoriere sieht TFrameNachfahre im Objektinspektor aus wie ein TForm.

[sh17]

hier die Antwort von OLLI_T

[tomsel]

Noch ein Gedanke:
Delphi verhaspelt sich bei den Frames, wenn man dem Projekt einen neuen Frame hinzufügt und anschließend die Deklaration so abändert, dass der Frame von einem anderen abgeleitet wird. Wenn man den Baseframe der Objektablage hinzufügt und den Nachfahren dann direkt vom Baseframe erben lässt, klappt es. Der Unterschied liegt in den DFM-Dateien. Diese beginnt bei einem "normalen" Frame mit 'object', bei einem abgeleiteten aber mit 'inherited'.

[Jens Schumann]

Zitat:

Zitat von tomsel

Noch ein Gedanke:
Delphi verhaspelt sich bei den Frames, wenn man dem Projekt einen neuen Frame hinzufügt und anschließend die Deklaration so abändert, dass der Frame von einem anderen abgeleitet wird. Wenn man den Baseframe der Objektablage hinzufügt und den Nachfahren dann direkt vom Baseframe erben lässt, klappt es. Der Unterschied liegt in den DFM-Dateien. Diese beginnt bei einem "normalen" Frame mit 'object', bei einem abgeleiteten aber mit 'inherited'.

SUPER - genau das ist es. Vielen Dank an Alle.

[sh17]

@tomsel

viel Schlau im Kopf :idea: wieder was gelernt

[Udontknow]

Wollte nur einmal "Danke" sagen für den Tip mit "inherited" in der DFM. Ich glaube, da hätte ich noch ein paar Tage mit der Suche nach dem Fehler zugebracht.

Danke! :thumb:

Cu,
Udontknow