Wichtiger Hinweis

[mse]

Hallo

Wichtiger Hinweis an MSEide+MSEgui-Nutzer:
Bitte lest http://thread.gmane.org/gmane.comp.ide.mseide.user/26263

Danke, Martin

[mschnell]

Hierzu eine Frage, die ich noch nie gestellt habe, weil ich es zwar testweise programmiert, aber noch nie ernsthaft gebraucht habe: Wie kann man eine visuell platzierte Komponente in realtime mit nicht visuellen Eigenschaften erweitern ?

Testbeispiel: Ein Button soll zusätzlich bei jede,m Click die Textfarbe toggeln.

- Zur Design-Zeit platziere ich einen normalen TButton "Button1" und verbinde das OnClick-Event mit einer entsprechenden Funktion-
- Zur Design-Zeit leite ich eine Kompnente TFunnyButton von TButton ab, die bei jedem Clich die Textfarbe Toggelt
- Zur Laufzeit kreiere ich einen TFunnyButton "FunnyButton1"und ersetze ich mit low-level Hacker-Methoden den Buttun1 durch den erweiterten FunnyButton1.

Das geht natürlich nur, weil die zusätzlichen Eigenschaften in der Virtual Method Table hinten angehängt werden. Das ist mit der Field-Optimization vermutlich nicht mehr möglich.

Gibt es eine empfohlene Vorgehensweise (außer die Komponente in einem Pakte zu kreieren und Lazarus neu zu kompilieren) ?

Gruß,
-Michael

[m.fuchs]

Also wenn ich dein Problem richtig verstehe, könntest du dir eine Art Helperklasse bauen, die sich an die Ereignisse von dem TButton hängt und auf das OnClick reagiert und dann das Ändern der Farbe übernimmt.

[mschnell]

Also wenn ich dein Problem richtig verstehe, könntest du dir eine Art Helperklasse bauen, die sich an die Ereignisse von dem TButton hängt und auf das OnClick reagiert und dann das Ändern der Farbe übernimmt.

Genau. Aber entsprechend dem Beitrag von mse gehen ja Helper Klassen nicht mehr.

(Ich habe auch nur ein Beispiel geschildert. Interessanter wird es natürlich, wenn man die visuelle Komponente aus der Library viel stärker erweitert und dann mehrfach verwenden will.)

-Michael

[m.fuchs]

Genau. Aber entsprechend dem Beitrag von mse gehen ja Helper Klassen nicht mehr.

Das habe ich jetzt nicht rausgelesen, aber eventuell verstehe ich das Problem nicht richtig.

[mschnell]

Das habe ich jetzt nicht rausgelesen.

"Because of a new FPC field order optimization it will not be possible in future to use cracker classes,..."

Ist "Helper-" und Cracker-" Klasse etwas unterschiedliches ?

-Michael

[m.fuchs]

Ist "Helper-" und Cracker-" Klasse etwas unterschiedliches ?

Aber ja, für Helperklassen als solche gibt es gar keine Definition. Außer dass es Hilfsklassen sind. Was mir vorschwebt, ist sowas:

Code: Alles auswählen

type
  TButtonFontChanger = class(TObject)
    private
      OriginalOnClick: TNotifyEvent;
      OriginalButton: TButton;
      procedure ButtonOnClick(Sender: TObject);
    public
      constructor Create(AButton: TButton);
      destructor Destroy; override;
  end;
 
  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
    procedure FormCreate(Sender: TObject);
    procedure FormDestroy(Sender: TObject);
  private
    FontChanger: TButtonFontChanger;
  end;
 
var
  Form1: TForm1;
 
implementation
 
procedure TButtonFontChanger.ButtonOnClick(Sender: TObject);
begin
  if fsbold in OriginalButton.Font.Style then
    OriginalButton.Font.Style := []
  else
    OriginalButton.Font.Style := [fsBold];
  if Assigned(OriginalOnClick) then
    OriginalOnClick(Sender);
end;
 
constructor TButtonFontChanger.Create(AButton: TButton);
begin
  OriginalOnClick := AButton.OnClick;
  OriginalButton := AButton;
  AButton.OnClick := @Self.ButtonOnClick;
end;
 
destructor TButtonFontChanger.Destroy;
begin
  OriginalButton.OnClick := OriginalOnClick;
  inherited Destroy;
end;
 
{$R *.lfm}
 
procedure TForm1.Button1Click(Sender: TObject);
begin
  Application.MessageBox('Hallo', 'Test', 0);
end;
 
procedure TForm1.FormCreate(Sender: TObject);
begin
  FontChanger := TButtonFontChanger.Create(Button1);
end;
 
procedure TForm1.FormDestroy(Sender: TObject);
begin
  FreeAndNil(FontChanger);
end;
 
end.

[theo]

Eine Cracker Klasse ist ein Hack, den man einsetzt um an protected (oder auch private?) Felder der Elternklasse zu kommen.

Class Helper sind hier beschrieben: http://wiki.freepascal.org/Helper_types#class_helper

Was Helferklassen sind, weiss ich auch nicht.

[mschnell]

Class Helper sind hier beschrieben: http://wiki.freepascal.org/Helper_types#class_helper.

Verstehe. Ist sicher manchmal sinnvoll einsetzbar. Anscheinend kann aber so ein Helper Typ nur Funktionen hinzufügen, aber nicht die interne Funktionalität verändern. Nützt also in meinem Beispiel vermutlich nix. Oder kann man in einem Helper vorhandene Funktionen überschreiben wie bei einem abgeleiteten Typ ?

-Michael

[Socke]

[quote="mschnell"Anscheinend kann aber so ein Helper Typ nur Funktionen hinzufügen, aber nicht die interne Funktionalität verändern. Nützt also in meinem Beispiel vermutlich nix. Oder kann man in einem Helper vorhandene Funktionen überschreiben wie bei einem abgeleiteten Typ ?[/quote]
Dein Beispiel hat mit der ganzen Thematik nichts zu tun . Das sind einfache Methodenaufrufe oder das Ändern von Eigenschaften.

Ich denke Cracker-Klassen machen Annahmen über das Speicherlayout von Objekten und umgehen dann die OOP-Zugriffsmöglichkeiten indem sie die Position von Feldern im Speicher berechnen und direkt darauf zugreifen.

Mit Helferklassen kannst du vorhandene Methoden überschreiben und hast auch Zugriff auf die ursprüngliche Implementation dieser Methode. Kurzes Beispiel:

Code: Alles auswählen

program Project1;
 
{$mode objfpc}
type
 
  tobj = class(Tobject)
    procedure pl();
  end;
 
procedure tobj.pl;
begin
  writeln('hallo, pl');
end;
 
type
  hc = class helper for tobj
    procedure pl();
  end;
 
procedure hc.pl;
begin
  writeln('hallo, helper');
  inherited pl;
end;
  
var
  o:  tObj;
begin
  o.pl;
  // ausgabe:
  // hallo, helper
  // hallo, pl
  readln;
end.

[mschnell]

Mit Helferklassen kannst du vorhandene Methoden überschreiben und hast auch Zugriff auf die ursprüngliche Implementation dieser Methode.

Super. Dann würde mein Beispiel damit möglicherweise funktionieren. Probiere ich bei Gelegenheit aus.

[m.fuchs]

Eine Cracker Klasse ist ein Hack, den man einsetzt um an protected (oder auch private?) Felder der Elternklasse zu kommen.

Nur an protected. Das müsste aber meines Erachtens auch mit den Neuerungen in FPC funktionieren. Würde aber bei dem geschilderten Problem auch nicht helfen.

Class Helper sind hier beschrieben: http://wiki.freepascal.org/Helper_types#class_helper

Acuh damit habe ich noch keine Lösung des Problems von mschnell gefunden. Was wohl auch daran liegt, dass in diesem Fall das ganz Button-geklickt-Geraffel nicht nru von TButton abgehandelt werden. Das landete ja schon bei den TWinControl. Und dann wird es wohl schwieriger, an der richtigen Stelle anzusetzen. Aber vielleicht weiß da ja jemand mehr.

Was Helferklassen sind, weiss ich auch nicht.

Einfach eine Klasse die Hilfsfunktionalität enthält. http://en.wikipedia.org/wiki/Helper_class Ein Beispiel dafür habe ich oben gepostet. Außer die Schrift bei Buttons fett zu machen, kann die Klasse nix weiter.

[martin_frb]

Hierzu eine Frage, die ich noch nie gestellt habe, weil ich es zwar testweise programmiert, aber noch nie ernsthaft gebraucht habe: Wie kann man eine visuell platzierte Komponente in realtime mit nicht visuellen Eigenschaften erweitern ?

Schau dir mal das an:
http://forum.lazarus.freepascal.org/ind ... l#msg97516

IMHO fällt es auch in die Kategorie "hacks". Es ist allerdings ok mit mit der neuen fpc Optimierung. Ob aber ansonsten zukunftssicher... ?

[m.fuchs]

Schau dir mal das an:
http://forum.lazarus.freepascal.org/ind ... l#msg97516

Genau, das wäre dann eine cracker class. Leider reicht das wohl nicht aus, für die Aufgabenstellung. Denn es soll ja das Verhalten erweitert werden und nicht nur die Sichtbarkeit von Methoden/Eiegnschaften.

[martin_frb]

Schau dir mal das an:
http://forum.lazarus.freepascal.org/ind ... l#msg97516

Genau, das wäre dann eine cracker class. Leider reicht das wohl nicht aus, für die Aufgabenstellung. Denn es soll ja das Verhalten erweitert werden und nicht nur die Sichtbarkeit von Methoden/Eiegnschaften.

Es wird ein Object der Ersatz-Klasse generiert. D.h. overridden Methods will kick in.

Zur mindestens ist das mit dem derzeitigen FPC so. Ob es so dokumentiert (und daher zukunftssicher) ist, weiß ich nicht.

Und es ist in dem Sinne Keine Cracker Class. Es greift in keiner weise illegal auf die bestehende Klasse zu.
Es verlaesst sich lediglich darauf, das der Reader, die neue Klasse findet und nutzt.

Ein Problem ist, das die Form, dann nur die neue, aber nicht die alte klasse beinhalten darf.