Tapi Callback Funktion darf nicht in Klasse sein

[DeddyH]

Das ist mir etwas zu viel Code zum schnellen Suchen, aber wird dwCallbackInstance nirgends gesetzt? Wenn die nirgends übergeben werden kann, ist ja der Parameter sinnlos.

[Jumpy]

Hab mich etwas selber verwirrt und daher eure Fragen nicht verstanden:

dwCallbackInstance kann u.a. mit irgend so einer anderen Tapi-Funktion gesetzt werden, aber die Tapi-Schnittstelle(?) unserer Telefonanlage unterstützt das nicht, d.h. da kommt immer 0 zurück. Scheinbar ist das von Anlage zu Anlage untersch. welche Tapi-Funktionalitäten genau unterstützt werden. D.h. da ist nix zu holen.

Mein Ziel ist es halt, das die sich nicht innerhalb einer Klasse befindliche CallBack-Prozedur, die ich der tapi bei der intitialisierung übergebe(n muss), die gefeuerten Events / Nachrichten, an meine Klasse weitergibt. Notfalls wohl dann wie bei Sir Rufo, wo die Callback auf eine global deklarierte Liste zugreifen kann in der sich (im meinem Fall nur die) eine Klasse registrieren kann, an die die Callbacks weitergeleitet werden sollen.

Der Ist-Zusatand den wir momentan haben gefällt mir halt nicht, z.B. welche Objekte wir da haben und wie die zueinander stehen. AUch fehlen mit Funktinalitäten, bisher wird die Anlage nur überwacht. Jetzt soll sie damit auch gesteuert werden können (z.B. Rufe umleiten usw.) Dazu bau ich das halt aus und um und wollt das irgendwie "sauber" hinkriegen, ohne die globale Variable MyTapi.

Bei Forms mach ich das auch so, ausser der Main-Form lösch ich immer alle diese Variablen ala Form2:TForm2 usw. aus den Units und leg mir entsprechedne Variablen da an wo ich das Form aufrufen will, und das wollt ich halt hier auch machen.

[Sir Rufo]

Zitat von Jumpy:

Mein Ziel ist es halt, das die sich nicht innerhalb einer Klasse befindliche CallBack-Prozedur, die ich der tapi bei der intitialisierung übergebe(n muss), die gefeuerten Events / Nachrichten, an meine Klasse weitergibt. Notfalls wohl dann wie bei Sir Rufo, wo die Callback auf eine global deklarierte Liste zugreifen kann in der sich (im meinem Fall nur die) eine Klasse registrieren kann, an die die Callbacks weitergeleitet werden sollen.

Aber das machst du doch schon ... du verwaltest doch schon eine Liste mit Callbacks

[Sir Rufo]

Allerdings hätte ich auch einiges an Verbesserungen zum Code:

1. MyTapi ist ein Singleton und sollte auch entsprechend implementiert werden z.B. mit einem Interface
   
   Delphi-Quellcode:

   interface
   
   type
     IFoo = interface
       ['{10C358B9-FCF2-4CAF-9F35-65DDDD4C6039}']
       procedure DoSomething;
     end;
   
   function MyFoo : IFoo;
   
   implementation
   
   type
     TFoo = class( TInterfacedObject, IFoo )
       procedure DoSomething;
     end;
   
   var
     _MyFoo : IFoo;
   
   procedure TFoo.DoSomething;
   begin
   
   end;
   
   function MyFoo : IFoo;
   begin
     if not Assigned( _MyFoo ) then
       _MyFoo := TFoo.Create;
     Result := _MyFoo;
   end;

2. Du verwaltest eine Liste mit Callbacks, die dann aufgerufen werden. Warum nimmst du dann nicht Methoden? Du rufst die auf, dann kannst du auch bestimmen, was du aufrufst.
   
   Delphi-Quellcode:

   type
     TTapiCallbackMethod = procedure ( hDevice, dwMsg, {dwCallbackInstance, } dwParam1, dwParam2, dwParam3 : Cardinal ) of object;

[Jumpy]

Das oben gezeigte ist auszugsweise der Ist-Zustand, von dem ich ja weg will. Daher sind Verbesserungsvorschläge gerne gesehen. Mein irgendwann fertiges TapiApp-Object soll wie z.Zt. MyTapi eine Liste von Callback-Funktionen verwalten. Diese können dann tatsächlich so aussehen wie ich das will, sprich welche Parameter usw. Zu deinem

Delphi-Quellcode:

type
  TTapiCallbackMethod = procedure ( hDevice, dwMsg, {dwCallbackInstance,  } dwParam1, dwParam2, dwParam3 : Cardinal ) of object;

könnte dann vllt. noch ein:
  TTapiCallbackMethods = Array of TTapiCallbackMethod kommen. Geht das? Oder sind so Methodenzeiger (das ist das doch) besser in einer T(Object)List o.ä. aufgehoben?

-------

Es gibt wenn man so will 2 Arten von Callback Funktionen. Eine "Master"-CallBack-Funktion für die Tapi ausserhalb von Objekten, die aber auch an mein Objekt alles weitergeben soll und dann andere Callback-Funktionen (diesmla gerne auch von anderen Objekten), die in meinem Objekt gelistet sind und an die so auch die ursprüngliche Tapi-Message (ggf. in angepasster Form) weitergegeben wird.

-------
Wenn ich nun MyTapi als Singelton (muss ich mir nochmal genauer anschauen) umsetzte, kann ich das denn auch in meiner aussserhalb von Objekten (nur im Application-Kontext) deklarierten CallFunktion benutzen?

[Sir Rufo]

Zitat von Jumpy:

könnte dann vllt. noch ein:
  TTapiCallbackMethods = Array of TTapiCallbackMethod kommen. Geht das? Oder sind so Methodenzeiger (das ist das doch) besser in einer T(Object)List o.ä. aufgehoben?

Völlig wumpe, die Struktur, wie gespeichert wird, würde ich eh nicht nach aussen geben. Das Interface hat einfach zwei Methoden: AddMethod, RemoveMethod. Den Rest interessiert keinen der von aussen schaut.

Zitat von Jumpy:

Wenn ich nun MyTapi als Singelton (muss ich mir nochmal genauer anschauen) umsetzte, kann ich das denn auch in meiner aussserhalb von Objekten (nur im Application-Kontext) deklarierten Funktion benutzen?

Öh, ja warum nicht ... das Singleton sorgt nur dafür, dass es max. 1 Instanz gibt, mehr nicht

[shmia]

Das Weiterleiten einer Callback-Funktion auf die Callback-Methode ist doch ganz einfach!

Delphi-Quellcode:

procedure priv_MyCallback(hDevice,
                          dwMsg,
                          dwCallbackInstance,
                          dwParam1,
                          dwParam2,
                          dwParam3: Cardinal); stdcall;
begin
  if dwCallbackInstance = 0 then
  begin
    // Oh ohhh, das sollte nie vorkommen (wäre ganz klar ein Fehler des Programmierers)
    Assert(False);
  end
  else
  begin
     try
        TMyTapi(dwCallbackInstance).MyCallback(hDevice,
                          dwMsg,
                          dwParam1,
                          dwParam2,
                          dwParam3);
    except
       // Exception loggen oder anzeigen
       // auf jeden Fall sollte keine Exception dem Aufrufer um die Ohren fliegen
    end; 
  end;
end;