Callback funktion in Objekten ?

[arbu man]

Hi,

Ich möchte eine Methode eines Objektetes als Callback Funktionen nehmen leider geht das nicht. Liegt diese Methode locker in einer Uinit geht es woran liegt das ?

Bsp:

Delphi-Quellcode:

type
  tmyclass = class
  public
    procedure setcallback;
    procedure callback;
  end;

...

procedure callback;
begin end;

procedure tmyclass.setcallback;
var 
  p:pointer;
begin
  p:= @self.callback; // geht nicht
  p:= @callback; // geht
end;

mfg, Björn

[SirThornberry]

@self.callback geht nicht weil Callback eine Methode der Klasse ist und nicht von der Instanz (schwer zu beschreiben). Folgendes geht:
@TMyClass.Callback

Allerdings gibt es für so etwas events.

Delphi-Quellcode:

TMyClass = class(TObject)
private
  [...]
  fEvent: TNotifyEvent; //oder anderer Callbacktyp
public
  OnEvent: TNotifyEvent read fEvent write fEvent;
end;
[...]
procedure TMyClass.DoCallback;
begin
  if Assigned(fEvent) then
    fEvent(Self);
end;

[markusj]

Delphi-Quellcode:

type TPCallback = procedure

procedure callback;
procedure setCallBack;
procedure callCallBack;

var cb : TPCallBack;

...


procedure callback;
 begin
 //dosomething
 end;

procedure setCallBack;
 begin
 cb := callback;
 end;

procedure callCallBack;
 begin
 cb;
 end;

Anmerkung: evtl. Musst du TPCallback = procedure of Object machen, wenn es sich um eine Prozedur/Funktion eines Objektes Handelt...

EDIT: Wieso ignoriert der meine Einückung?

[arbu man]

Events kann ich schlect benutzen da ich die callback funtion für eine DLL benötige.

Wenn ich @TMyClass.Callback benutze wo wird das dann überall ausgelöst, wenn ich z.B. 10 Objuekte vom Typ meiner klasse habe wird dann das ereignis in allen objekten ausgelöst oder nur in einen und wenn ja in welchen ?

@markusj: geht das auch zwischen anwendung und dll ?

[SirThornberry]

wenn du mit DLL's arbeitest und somit nicht mit "of Object" arbeiten kannst/willst dann darfst du auch keine Methode (procedure einer Klasse) nehmen sondern dann sollte es auch eine richtige Procedure sein. Denn sobald es eine Methode ist entspricht dies dem "of Object" wo der unsichtbare Self-parameter dabei ist.

bei @TKlasse.Callback musst du den unsichtbaren selfparameter sonst selbst mitgeben denn intern sieht die Procedure so aus:
procedure Callback(Self: TYourClassName)

[markusj]

Ich habe noch nie mit DLLs gearbeitet, aber da afaik auf Indy damit arbeitet (mal ganz von Luckie abgesehen, Boardsuche ...), denke ich ja, da im Endeffekt nur ein Prozedurzeiger übergeben wird.
Die Prozedur, auf die gezeigt wird, muss ganz bestimmte Bedingungen betreffend der Schnitstelle erfüllen ... dass sind die, die bei der Typdeklaration festgelegt werden.

mfG

Markus

Roter Kasten: stimmt, sowas hab ich mal gelesen ... du musst der DLL genau das geben, was dabei ist ... wenn die byte, longword, char will, dann will die das in der Reihenfolge haben ... ein Self-Parameter, wie er bei of Objekt übergeben wird, fürht dann zu einer Exception ...

[arbu man]

D.h. es gibt einen einfacheren weg mit klassen und dlls zu arbeiten, also werde ich wohl nicht um eine "richtige" procedure herumkommen

[SirThornberry]

wenn du die ShareMem einbindest kannst du zwischen DLL und hauptprogramm alles mögliche machen (auch mit klassen, events etc. arbeiten)

Ich hab in einem projekt mit Wrapper gearbeitet. Die DLL exportiert also ganz normale Proceduren wo ich als ersten Parameter immer ein Handle (entspricht in Etwa dem Self) mitgebe

[arbu man]

Zitat von SirThornberry:

wenn du die ShareMem einbindest kannst du zwischen DLL und hauptprogramm alles mögliche machen (auch mit klassen, events etc. arbeiten)

Damit bin ich aber dann komplett auf delphi(compiler) beschränkt oder ?

Zitat:

Ich hab in einem projekt mit Wrapper gearbeitet. Die DLL exportiert also ganz normale Proceduren wo ich als ersten Parameter immer ein Handle (entspricht in Etwa dem Self) mitgebe

Eine sehr gute möglichkeit zu mal ein objekt eh ein handle hat (TForm), somit könnte sich die procedure di form mit dem handle nehmen und die daten weiterleiten thanks