Polymorphie mit eigenen Frames: TabOrder nicht gefunden

[Neg]

Moin moin... Bin neu hier und hab auch gleich eine Frage. :mrgreen: :angle2:

Achtung, wird etwas länger, aber der größte Teil des Quellcodes zeigt nur den Kontext des Problems und kann schnell überflogen werden.

Also, in meinem Programm erstelle ich dynamisch zur Laufzeit Seiten für ein PageControl. Diese Seiten sehen folgendermaßen aus:

Delphi-Quellcode:

type
  TFileSheet = Class(TTabSheet)
    private
    FileName: String;
    Modified: Boolean;
    Mode: TGenerationMode;
    ID: integer;
    AddRule: TAdditionalRules;
    ContentFrame: TSheetFrame;
  end;

Der ContentFrame wird von verschiedenen Klassen, die von TSheetFrame abgeleitet wurden, instanziiert, z.B. so:

Delphi-Quellcode:

case Mode of
SimpleMode:
  begin
  SheetFrame:=TFrameSimpleMode.Create(FileSheet[c]);
  InitSheetFrame(SheetFrame as TFrameSimpleMode);
  end;
AdvancedMode:
  begin
  SheetFrame:=TFrameAdvMode.Create(FileSheet[c]);
  InitSheetFrame(SheetFrame as TFrameAdvMode);
  end;
// usw...
else SheetFrame:=NIL;
end; {of case}

FileSheet[c].ContentFrame:=SheetFrame;
SheetFrame.Parent:=FileSheet[c];

Ein TSheetFrame ist übrigens lediglich eine Interface-Klasse folgender Gestalt:

Delphi-Quellcode:

type
  TSheetFrame = Class(TFrame)
  public
      procedure RefreshLanguage; virtual; abstract;
  end;

Die Polymorphie ist eigentlich nur dafür gut, damit ich später, wenn man zur Laufzeit die Sprache umstellt, folgendes schreiben kann:

Delphi-Quellcode:

for i:=0 to PageControlMode.PageCount-1 do
    begin
    FileSheet[i].ContentFrame.RefreshLanguage;
    end;

So, jetzt das eigentlich Problem:
Damit die Polymorphie funktioniert, muss ich ja meine Frames von TSheetFrame statt von TFrame ableiten. Also habe ich einfach überall in dem automatisch generierten Code die Klassen-Deklaration entsprechend umgeändert.
Vorher:

Delphi-Quellcode:

type
  TFrameSimpleMode = class(TFrame)
    ComboBoxTemp: TComboBox;
    LabelTemplate: TLabel;
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
    procedure RefreshLanguage; override;
  end;

Nachher:

Delphi-Quellcode:

type
  TFrameSimpleMode = class(TSheetFrame)
    ComboBoxTemp: TComboBox;
    LabelTemplate: TLabel;
  private
    { Private-Deklarationen }
  public
    { Public-Deklarationen }
    procedure RefreshLanguage; override;
  end;

Alles funktioniert wie es soll.
Aber: Nachdem ich das Projekt geschlossen hatte, konnte ich mir nach dem Öffnen nicht mehr die Frames (den Code oder das Form) anschauen, ohne die angehängte Fehlermeldung präsentiert zu bekommen. Danach lässt sich das Programm nicht mehr compilieren! Wenn ich mir aber nach dem Öffnen kein Frame anschaue, dann lässt sich das Programm aber normal compilieren und starten.

Offensichtlich kommt Delphi irgendwie nicht damit klar, dass ich an den "von ihm" kreierten Frames rumgefuscht habe. Ich würde jetzt aber gerne wissen, was genau das Problem ist. Wie würde man das richtig machen (mit Polymorphie). Ich habe das Problem inzwischen ohne Polymorphie -mit case und typecasts- gelöst. Ich möchte aber gerne wissen, warum es nicht so ging wie ich es versuchte.

PS: Der erste, der eine gute Antwort abliefert, kriegt ein virtuelles Bier spendiert. :mrgreen: :cheers:

[Neg]

*push*

[choose]

Hallo Neg,

weil ich nur der erste sein möchte, der Dir hier antwortet ("Beer!"), möchte ich Dich an dieser Stelle lediglich auf Interfaces hinweisen.
Eine Lösung der Art

Delphi-Quellcode:

type 
  IMyInterface = interface
  ['YourGUID']
    procedure RefreshLanguage;
  end;

  TMyFrame = class(TFrame, IMyInterface)
  protected
    procedure RefreshLanguage;
  end;

  TForm1 = class(TForm, IMyInterface)
  protected
    procedure RefreshLangauge;
  end;

sollte darüber hinaus die Erweiturung des Konzepts auf andere Klassen (zB TForm) ermöglichen, die nicht von einer abstrakten Oberklasse erben, ohne das der Client (Aufrufer) angepasst werden muss:

Delphi-Quellcode:

var
  myInterface: IMyInterface;
  myFrame: TMyFrame;
begin
  myFrame:= TMyFrame.Create(AForm);
  with myFrame do
    //...
  
  // use instances' interface
  myInterface:= myFrame;
  myInterface.RefreshLanguage;
  myInterface:= AForm;
  myInterface.RefreshLanguage;
  // syntactical suggar
  (myFrame as IMyInterface).RefreshLanguage;
  (AForm as IMyInterface).RefreshLanguage;

Ich empfehle Dir weiterhin eine Registratur aller anpassbaren Elemente (zB in Form eines singelton pattern) zu etablieren, bei der Sich die entsprechenden Komponenten bei der Erzeugung registrieren bzw beim Freigeben abmelden

Delphi-Quellcode:

constructor TMyFrame.Create(..);
begin
  inherited;
  TLanguageSingelton.Instance.Register(Self);
end;

um später zB mit dem Aufruf

Delphi-Quellcode:

TLanguageSingelton.Instance.RefreshLanguage;

alle zu aktualisierenen Exemplare zu iterieren unabhängig davon, auf welchen Controls sie sich tatsächlich befinden...

Falls Du später mehrere solcher Funktionalitäten zur Verfügung stellen solltest, könnte dieser Ansatz jedoch schnell in sog "god-interfaces" ausarten. Für diesen Fall könnte man lieber ein Delegations-Objekt oder die simplifizierte Delphi-Variante, ein Ereignis, registrieren, dass das alleinige Wissen über die durchzuführenden Aktionen hat...

[Neg]

Aha. Das sieht interessant aus.

Sehe ich das richtig, dass TMyFrame = class(TFrame, IMyInterface) im Grunde so etwas wie eine Mehrfachvererbung ist, nur dass die zweite Klasse eben keine "richtige Klasse", sondern nur ein Interface ist - so, als würde ich z.B. in C++ eine Klasse als abstrakt deklarieren und ihre Methoden nicht implementieren, also nur Siganturen liefern (Interface-Klasse)?

[choose]

Das implementieren eines Interfaces (IMyInterface) kann man in C++ tatsächlich mit dem Merfacherben einer puren abstrakten Klasse (IMyInterface) vergleichen, allerdings wäre diese pure abstrakte Klasse wiederum von der abstrakten Klasse IInterface abgeleitet, die drei abstrakte Methoden (_AddRef, _Release und QueryInterface) einführt und den Zuweisungsoperator operator = () in der Form überlädt, dass eine Zuweisung eines Objekts (!=null eq <>nil) die vom Erben zu implementiernde Methode _AddRef aufruft und das aufheben einer Referenz (bzw Zuweisen von nil) die vom Erben zu implementiernde Methode _Release aufruft (Referenzzählung).
Der Compiler sorgt darüber hinaus dafür, dass diese "Zuweisung mit nil" (durch Try..Finally geschützt) auch beim Verlassen des Gültigkeitbereichs durchgeführt wird, ähnlich dem C++ Konzept der SmartPointer (tatsächlich gibt es mit TInterfacedObject bereits ein Objekt, dass sich "selbst freigibt").

Suche einfach mal im Forum nach Interface etc, hier wurden oft schon gute Erklärungen für Einsteiger verfasst.

Eine kleine Anmerkung zur beschriebenen Lösung mit TMyFrame (s.o.): Die Klasse TComponent implementiert bereits die von IInterface (bei Deinem D5 heißt es IUnknown) geforderten Methoden und führt zur Referenzzählung (im Normalfall) eine Dummyoperation aus.

[negaH]

Baue eine separate Unit die du in einem DesignTime Package installierst. In dieser Unit sollte inetwa folgendes stehen:

Delphi-Quellcode:

unit RegMySheets;

interface

uses DesignIntf, DesignEditors;

procedure Register;

implementation

uses ....;

procedure Register;
begin
  RegisterCustomModule(TSheetFrame, nil);
end;

Ab D6 oder D7 musst du bei der Delphi IDE einen Klassen-Editor registrieren.

Gruß Hagen