![]() |
AW: Tapi Callback Funktion darf nicht in Klasse sein
Zitat:
|
AW: Tapi Callback Funktion darf nicht in Klasse sein
Allerdings hätte ich auch einiges an Verbesserungen zum Code:
|
AW: Tapi Callback Funktion darf nicht in Klasse sein
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:
könnte dann vllt. noch ein:
type
TTapiCallbackMethod = procedure ( hDevice, dwMsg, {dwCallbackInstance, } dwParam1, dwParam2, dwParam3 : Cardinal ) of object;
Delphi-Quellcode:
kommen. Geht das? Oder sind so Methodenzeiger (das ist das doch) besser in einer T(Object)List o.ä. aufgehoben?
TTapiCallbackMethods = Array of TTapiCallbackMethod
------- 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? |
AW: Tapi Callback Funktion darf nicht in Klasse sein
Zitat:
Zitat:
|
AW: Tapi Callback Funktion darf nicht in Klasse sein
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; |
AW: Tapi Callback Funktion darf nicht in Klasse sein
Das ist doch ziemlich genau das, was ich weiter vorn bereits gesagt habe. Mir ist nur noch nicht klar, wie man dwCallbackInstance belegen kann.
|
AW: Tapi Callback Funktion darf nicht in Klasse sein
Zitat:
|
AW: Tapi Callback Funktion darf nicht in Klasse sein
Zitat:
Zitat:
Delphi-Quellcode:
Sehe leider nicht, wie ich das gebrauchen kann, um auf mein Objekt zu zeiegn. Werde also versuchen mein TapiApp-Object als Singelton zu implementieren.
var priv_hInstance:Cardinal;
priv_hInstance := hInstance; //hInstance aus Sysinit lineInitializeEX(@priv_LineApp,priv_hInstance,priv_MyCallback,//... |
AW: Tapi Callback Funktion darf nicht in Klasse sein
Zitat:
|
AW: Tapi Callback Funktion darf nicht in Klasse sein
Kommando zurück. Hab komplett an der falschen Stelle gesucht. Der Parameter wird bei lineOpen übergeben, das man für jede Telefonleitung, die man überwachen will, aufruft.
Zitat:
Also ist es ja vllt. doch möglich da einen Verweis auf mein Objekt hinzukriegen. Hoffe es hilft mir noch jemand nach der ganzen Verwirrung. Wenn ich innerhalb meines Objectes für jede Line lineOpen aufrufe, wie kann ich dann dabei einen Pointer(?) auf mein Objekt in dwCallbackInstance mitgeben, das ja vom Typ DWORD ist? Und wie muss ich dieses DWORD in der Callback-Funktion auswerten, um da wieder auf mein Objekt zu kommen? So wie shmia das andeutet, indem ich das in mein Objekt caste? TMyTapi(dwCallbackInstance). |
Alle Zeitangaben in WEZ +1. Es ist jetzt 21:44 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz