Generisches Typecasting?

[Stevie]

Hi Leute,

ich möchte dem ActiveControl mit Perform eine WindowsMessage schicken, allerdings möchte ich dazu das Objekt als Objekt seiner Klasse haben und nicht als TWinControl. Wie mache ich das?
Meine Idee sieht folgendermaßen aus (Pseudocode!):

Delphi-Quellcode:

  (ActiveControl as ActiveControl.ClassType).Perform(...);

Klar, dass das so nicht geht, aber wie kann ich das umsetzen?

:wall: Ok, dass es mit Perform nicht ging, hatte ne andere Ursache, und da spielt es ja keine Rolle, was das Objekt für eine Klasse hat, weil ja über das Handle SendMessage aufgerufen wird. Trotzdem interessiert mich die Lösung der ursprünglichen Frage noch.

[Muetze1]

Moin!

Du musst das zu TWinControl typecasten, da er bei einem TypeCast wie oben bei dir die Methode nicht kennt. Der Compiler kann nicht feststellen ob es die Methode bei dem Typ gibt zu Compile-Zeit und daher geht es nicht. Und selbst wenn du es auf TWinControl typecastest sollte die Perfom() Botschaft an das spezielisierte Element gehen bzw. dort verarbeitet werden.

MfG
Muetze1

[Stevie]

Zitat:

Zitat von Muetze1

Du musst das zu TWinControl typecasten, da er bei einem TypeCast wie oben bei dir die Methode nicht kennt. Der Compiler kann nicht feststellen ob es die Methode bei dem Typ gibt zu Compile-Zeit und daher geht es nicht. Und selbst wenn du es auf TWinControl typecastest sollte die Perfom() Botschaft an das spezielisierte Element gehen bzw. dort verarbeitet werden.

Siehe meinen geänderten Beitrag oben... :angel2:

[Muetze1]

Moin!

Ja, wie gesagt: Der Compiler kann es nicht compilieren, da er die Eigenschaft oder Typ nicht kennt. Der Typecast wird während der Laufzeit erst möglich, da zur Compile Zeit nicht weiss, welches Objekt denn ActiveControl ist. Daher kann er keine Informationen ermitteln, ob die Eigenschaft oder Methode die du spezialisiert nach dem TypeCast aufrufen willst überhaupt existiert. Und sobald er dies nicht weiss, kann er keinen Code generieren, da ihm die Info's dazu fehlen.

MfG
Muetze1

[samson]

Hallo!!!

Meinst DU sowas in der Art:

Delphi-Quellcode:

if self.ActiveControl is TEdit then
  (self.ActiveControl as TEdit).Perform(...);

[Stevie]

Zitat:

Zitat von samson

Meinst DU sowas in der Art

Jo, allerdings will ich nicht alle Objektklassen aufzählen, die es so gibt... :zwinker:

[samson]

Was hast Du eigentlich vor? Vielleicht kann der Sinn des Programms weiterhelfen.

Die Methode Perform hat doch auch ein TWinControl, wieso musst Du dann Casten??


Gruß


Frank

[Stevie]

Zitat:

Zitat von samson

Die Methode Perform hat doch auch ein TWinControl, wieso musst Du dann Casten??

Siehe oben...

Zitat:

Zitat von samson

Was hast Du eigentlich vor? Vielleicht kann der Sinn des Programms weiterhelfen.

Angenommen, ich habe zwei mehrere verschiedene Komponenten aus verschiedenen Klassen (kommt auf einem Formular schonmal vor... :mrgreen:) und die haben alle die gleiche Methode, die entweder nicht in TWinControl implementiert sind oder aber in einer Nachfahrenklasse überschrieben wurden. Wenn sie nicht vorhanden sind, ist der Fall klar, dann geht's sowieso nicht. Wenn sie aber in einer Nachfahrenklasse überschrieben wurden, dann kommt diese Methode überhaupt nicht zum Zuge, sondern die in TWinControl. Deshalb das TypeCasting, damit mit der "richtigen" Klasse gearbeitet wird.

[Stevie]

Hat echt keiner eine Idee, wie sowas gehen könnte???

[Muetze1]

Moin!

Ich habe dir doch nun schon versucht zu schreiben warum es nicht gehen kann, also in wie fern sollte es denn nun noch eine Lösung dazu geben? Unter .NET kannst du es mit dem JustInTime Compiler machen und direkt Quellcode zur Ausführung geben aber mit Delphi Boardmitteln musst du dich immer auf die Klassenebene einigen die die gesuchte Methode bietet.

MfG
Muetze1

[Stevie]

Zitat:

Zitat von Muetze1

Ich habe dir doch nun schon versucht zu schreiben warum es nicht gehen kann, also in wie fern sollte es denn nun noch eine Lösung dazu geben?

Nun, es gibt in der RTTL doch die Möglichkeit dynamisch die published Elemente dynamisch auszulesen, gell?
Und für Libraries gibt es die Möglichkeit dynamisch irgendwelche Funktionen zu laden und auszuführen.
Dann könnte es doch auch möglich sein, anhand der Klasseninformation eine Funktion zu finden und auzuführen, oder?
Es ist ja schließlich auch möglich dynamisch irgendwelche Klassen zu erstellen, wenn sie registriert sind.

[maximov]

Ja, wenn die published sind ist das kein problem. Einfach den pointer holen und eine methoden-variable zusammen basteln:

Delphi-Quellcode:

type
  TMyCall = procedure of object;
var
  method:TMethod;
...
method.data := myObj;
method.code := myObj.MethodAddress('Perform');
...
if method.code <> nil then TMyCall(method); // dies ist der aufruf!

// edit: verdammte kommentare

[Muetze1]

Moin!

Zitat:

Zitat von Stevie

Nun, es gibt in der RTTL doch die Möglichkeit dynamisch die published Elemente dynamisch auszulesen, gell?

Mit den RTTI Informationen kannst du zur Laufzeit published Properties finden und "bearbeiten" - richtig. Bei deinem TypeCast müssten aber die RTTI Informationen Informationen für alle Methoden ausser private haben - die gibt es nicht und daher sind die Methoden schlecht zu finden in der Laufzeit.

Zitat:

Zitat von Stevie

Und für Libraries gibt es die Möglichkeit dynamisch irgendwelche Funktionen zu laden und auszuführen.

Die DLL's haben eine Tabelle wo der Name und/oder Index zu der Funktion drinne steht und anhand der Informationen wie auch die ganzen Relocation Informationen kann der Code Teil geladen, angepasst und ausgeführt werden. Diese Informationen fehlen einem auch hier wiederrum.

Zitat:

Zitat von Stevie

Dann könnte es doch auch möglich sein, anhand der Klasseninformation eine Funktion zu finden und auzuführen, oder?

Welche Klasseninformationen? Den Klassennamen kann man ja noch ohne Probleme rausfinden - da bietet dir ja TObject schon die Methode ClassName an, aber es werden keine Informationen vorgehalten über alle Methoden in der Klasse (bis auf die private Methoden) wie schon oben gesagt, daher hat man wenig Chancen. Und der Compiler wird bestimmt nicht über alle in dem Programm verwendeten Klassen eine Sprungtabelle aufbauen mit den Offsets zu alles möglichen Methoden und deren Namen.

Zitat:

Zitat von Stevie

Es ist ja schließlich auch möglich dynamisch irgendwelche Klassen zu erstellen, wenn sie registriert sind.

Das ist doch wieder was anderes: Dort wird doch nur eine MetaClass angelegt die die Klassen aufnehmen und somit könnten sie ja instanziiert werden. Das Problem ist hierbei aber das gleiche wie bei dir: Es können von den so instanziierten Instanzen nur die Methoden aufgerufen werden, die auch die Basis-Metaklasse auch kennt. D.h. wenn die Basis MetaKlasse von TObject stammt (Class Of TObject), dann kannst du dort kein Perform in den über den Weg instanziierten Instanzen aufrufen ohne Spezialisierung über einen speziellen (zur Compile Zeit schon definierten) TypeCast. Wenn du nun aber die Metaklasse vom Typ TWinControl aufbaust (Class Of TWinControl), dann kennen auch die Instanzen eine Methode Perform ohne Spezialisierung über einen direkten TypeCast. (Ich gehe davon aus, das Perform public ist ab TWinControl - dahingehend habe ich nicht nachgeschaut ob dem so ist).

Im Endeffekt ist es so, das bei allen deinen Beispielen extra dafür Vorkehrungen getroffen wurden damit dies möglich wird, nicht aber in dem Fall wo du die Informationen suchst.

@Maximov: Der o.g. Code sollte beim Aufruf eigentlich gut in die Hose gehen, da die Aufrufparameter fehlen und dadurch der Stack schiefer hängen sollte als der Haussegen.

MfG
Muetze1

[OregonGhost]

Zitat:

Zitat von Stevie

Wenn sie nicht vorhanden sind, ist der Fall klar, dann geht's sowieso nicht. Wenn sie aber in einer Nachfahrenklasse überschrieben wurden, dann kommt diese Methode überhaupt nicht zum Zuge, sondern die in TWinControl. Deshalb das TypeCasting, damit mit der "richtigen" Klasse gearbeitet wird.

Moment. Drehen meine OOP-Kenntnisse jetzt durch oder was ist los? Wozu gibt's Polymorphie? Damit ich einen Basisklassenzeiger (oder halt eine Referenz) wie TWinControl habe, dessen Methode aufrufe und trotzdem die Methode der Klasse, aus der das Objekt letztendlich instanziiert wurde (wie TEdit), ausgeführt wird. Oder nicht? Wo ist das Problem? Es wird doch immer die überschriebene Methode ausgeführt.
Denn du erkennst ja schon, das das nicht funktioniert, wenn die Funktion nicht in der Basisklasse enthalten ist, folglich beziehst du dich schon auf die Polymorphie (denn ohne Polymorphie bist du nicht daran gebunden, was du von wem aufrufst).

Oder ist das jetzt ein Denkfehler meinerseits und du willst was ganz anderes? :gruebel:

[Stevie]

So'n Mist!!! :evil: Aber danke für die eingehene Erklärung, hab mir das wohl zu einfach vorgestellt. :roll:
Aber mal angenommen, eine von TWinControl abgeleitete Klasse hat eine Methode published gemacht, kann ich dann das von maximov gepostete Beispiel anwenden?

Nachtrag:
Tja, ich hab eben gedacht, ich könnte genau sowas wie Polymorphie benutzen, obwohl die Methoden überhaupt als polymorph deklariert sind... :pale:

[maximov]

Zitat:

Zitat von Muetze1

Moin!

...
@Maximov: Der o.g. Code sollte beim Aufruf eigentlich gut in die Hose gehen, da die Aufrufparameter fehlen und dadurch der Stack schiefer hängen sollte als der Haussegen.

MfG
Muetze1

Jeder, der so etwas macht ist selbst dafür verantwortlich, das die methode die richtigen parameter erhält :shock: ...is nicht ganz eifach das zur laufzeit zu entscheiden, da keinerlei infos über die signatur der methoden vorliegen, aber wenn man sich ein paar konventionen aufstellt kann man das vertreten.

..

Wie auch immer. Ich würd auch eher auf Polymorphie zurück greifen.

[Phoenix]

Zitat:

Zitat von OregonGhost

Moment. Drehen meine OOP-Kenntnisse jetzt durch oder was ist los? Wozu gibt's Polymorphie? Damit ich einen Basisklassenzeiger (oder halt eine Referenz) wie TWinControl habe, dessen Methode aufrufe und trotzdem die Methode der Klasse, aus der das Objekt letztendlich instanziiert wurde (wie TEdit), ausgeführt wird. Oder nicht? Wo ist das Problem? Es wird doch immer die überschriebene Methode ausgeführt.
...
Oder ist das jetzt ein Denkfehler meinerseits und du willst was ganz anderes? :gruebel:

Letzteres.

Du hast folgendes Problem:
Du hast ein TButton, der aber als TWinControl gecastet ist.
Der Compiler geht also innerhalb der Methode davon aus, das Du nur ein TWinControl hast. Wird in diesem Moment eine Methode aufgerufen wie z.B. Repaint setzt der Compiler die Sprungadresse zu TWinControl.Repaint ein. Da hilft das nichts, das Dein Objekt ein TButton ist und Repaint dortdrin eigentlich überschrieben wäre, da das der Compiler der die Sprungadresse dorthin compiliert nix davon weiss.

Du musst tatsächlich TButton(Object).Repaint aufrufen um die überschriebene Methode zu nehmen.

[maximov]

Zitat:

Zitat von Phoenix

...

Letzteres.

Du hast folgendes Problem:
Du hast ein TButton, der aber als TWinControl gecastet ist.
Der Compiler geht also innerhalb der Methode davon aus, das Du nur ein TWinControl hast. Wird in diesem Moment eine Methode aufgerufen wie z.B. Repaint setzt der Compiler die Sprungadresse zu TWinControl.Repaint ein. Da hilft das nichts, das Dein Objekt ein TButton ist und Repaint dortdrin eigentlich überschrieben wäre, da das der Compiler der die Sprungadresse dorthin compiliert nix davon weiss.

Du musst tatsächlich TButton(Object).Repaint aufrufen um die überschriebene Methode zu nehmen.

Denk da nochmal drüber nach! Entweder hast du dir ein schlechtes beispiel gesucht oder Polymorphy nicht verstanden (nicht böse sein). ABER selbstverständlich wird in diesem fall TButton.Repaint aufgerufen, denn sie wurde ja explizit von TButton überschrieben.

ODer wie darf ich dich verstehen?

[Muetze1]

Moin!

Nein, da er in die VMT Tabelle ausgehend von der aktuellen Instanzenadresse reinspringt, springt er an die Position der RePaint Procedure die der Button aber in der Instanz mit seiner eigenen Adresse überschrieben hat. Er wird bei dem Vorgehen trotzdem das Repaint des Buttons aufrufen.

Probiere es aus!

MfG
Muetze1