Frames und Vererbung

[Sieben]

Moin,

ich möchte mir einen kleinen Editor als Frame erstellen, den ich an verschiedenen Stellen einsetzen kann, und zwar einmal mit einem einfachen TRichMemo und einmal mit einem TDBRichMemo. Dazu habe ich zunächst mal einen Frame mit eingebettetem TRichMemo erstellt und eine Toolbar angelegt mit den üblichen Buttons für fett, kursiv etc. Funktioniert alles auch soweit. Dann habe ich das TRichMemo entfernt und durch eine Variable

FRichEdit: TCustomRichMemo;

ersetzt. Dann einen Frame erstellt, der von diesem Basis-Frame abgeleitet ist und in dessen Constructor eine Instanz von TRichMemo für diese Variable erstellt. Das kompiliert auch alles, und der neue Frame erscheint auch wie erwartet, und auch die Methoden, die mit dieser Variablen arbeiten, werden 'anstandslos' (dh ohne Schutzverletzung odgl) durchlaufen - nur funktionieren tun sie leider nicht bzw liefern andere Ergebnisse als mit einer aus der *.lfm des Basis-Frames erzeugten Instanz. Ich steh da jetzt etwas auf dem Schlauch

a) warum das so ist
b) wie man das 'richtig' macht.

Ich möchte eben letztlich nicht zwei Frames haben, die jeweils den ganzen Formatierungscode doppelt mitschleppen.

[af0815]

Mit den beiden Frames im Anhang, kann ich das einmal nicht nachvollziehen, was da nicht gehen soll. Was heisst gehen nicht bzw. liefern andere Ergebnisse. Kannst du da auch komplette Beispiele liefern ?!

[Sieben]

Sorry, habe noch mal ein Testprojekt beigelegt sowie unter /works die funktionierende Ursprungsversion des Frames. Wo in diesem eine selektierte Textstelle nach Betätigen des entsprechenden Buttons zb fett wird, verschwindet sie in dem abgeleiteten einfach. 'Funktioniert nicht' war in der Tat eine selten dämliche Beschreibung...

[shokwave]

HI,

du musst das OnSelectionChange Ereignis noch implementieren. So wie du es auch in deinem funktionierenden Test gemacht hast. Sonst sind die Font/Fontattribute, wo du was mit SetTextAttributes hinzufügen oder wegnehmen willst, leer und dann kommt Quatsch raus.

Code: Alles auswählen

type

  { TfrCustomRichEditor }

  TfrCustomRichEditor = class(TFrame)
  .....
  private
    ....
    procedure SelectionChange(Sender:TObject); 
    .....
   
implementation         
    
constructor TfrCustomRichEditor.Create(TheOwner: TComponent);
begin
  inherited Create(TheOwner);
  FRichEdit:=TRichMemo.Create(Self);
  FRichEdit.Parent:= Self;
  FRichEdit.Align:= alClient;
  FRichEdit.OnSelectionChange:=@SelectionChange;
....


procedure TfrCustomRichEditor.SelectionChange(Sender: TObject);
begin
  FRichEdit.GetTextAttributes(FRichEdit.SelStart, FFontParams);
  UpdateToolBar;
end;
 

[Sieben]

Vielen Dank, das dürfte es sein... kann es sein, dass gestern Montag war?

Edit: yep. Im abgeleiteten Frame:

Code: Alles auswählen

  //...
  with FRichEdit do
  begin
    OnSelectionChange := @EditSelectionChange;
    //...

und es läuft. Besten Dank noch mal!

[shokwave]

Definitiv!

[Sieben]

Noch eine Beobachtung, die tatsächlich mit Vererbung zu tun hat: wenn ich im Basis-Frame eine Komponente lösche, danach einen Abkömmling aufrufe, der zu dieser Komponente bereits etwas in seiner .lfm gespeichert hat, meldet die IDE erwartungsgemäß einen nicht gefundenen Vorfahren zu diesem Eintrag. Wählt man dann das voreingestellte 'Laden der Ressource abbrechen', so knallt es ganz gewaltig, und zwar so heftig wie auch hier beschrieben (und wie ich es anhand des dortigen Beispiels auch mit 2.0.10 nachvollziehen konnte). Das finde ich schon bemerkenswert, da ich die IDE eigentlich als erstaunlich stabil und 'forgiving' kennengelernt habe. Vielleicht hat sich da tatsächlich ein Bug in's Streaming-System eingeschlichen?

Wählt man dagegen 'Laden fortsetzen', läuft alles glatt, und der Abkömmling erscheint ohne die im Vorläufer gelöschte Komponente. Es wäre dann allerdings schön, wenn die IDE den Abkömmling auch als geändert bzw zum Speichern vormerken würde. Im Moment wird eine bereinigte .lfm nur geschrieben, wenn noch weitere Veränderungen vorgenommen werden.

[af0815]

Ich verwende Frames nur dynamisch im Code. Niemals direkt, auch aufgrund von Seiteneffekten, wenn etwas in der Basisversion gelöscht oder stark geändert wurde. Auch die Bindungen erstelle ich immer zur Laufzeit.

Da ich komplexe Frame in Frame Strukturen verwende, habe ich oft eigen Testumgebungen damit ich die Frames alleine testen kann. Damit erspare ich mir im eigentlichen Projekt ärger. So kann ich das einzelne Frame komplett auf Funktion testen, dann wird das in die eigentliche App eingeklingt, parametriert und läuft. Falls was nicht ganz rund läuft, so kann ich das wieder in der Testumgebung mit definierten Parametern testen.

[Sieben]

Danke, so werde ich es dann wohl auch (wieder - in Delphi war das ja auch nicht ohne Probleme oder Seiteneffekte) halten. Im Moment möchte ich aber auch erst mal nur sehen, was Lazarus in dieser Hinsicht so bietet und wo hier die Fallstricke sind. Und ich bin in der glücklichen Lage, das nur noch zum Privatvergnügen zu betreiben und benötige daher auch keine ganz so komplexen Strukturen mehr, die verschiedenste Umgebungen und alle möglichen Weiterentwicklungen berücksichtigen müssen. An seiner eigentlichen Wirkungsstätte würde ich einen Frame aber auch immer nur zur Laufzeit erzeugen und verkabeln.