DLL Callback Merkwürdigkeiten

[haentschman]

Danke...

Das Geheimnis war das:

Delphi-Quellcode:

// procedure DoWork(TagName, TagValue: PChar);
class procedure DoWork(TagName, TagValue: PChar); static;

[himitsu]

Und, du hast über einen typlosen Zeiger sämtliche Typprüfungen umgangen.
Wenn man das nicht nacht, dann würde einem der Compiler auch brav sagen können, dass hier etwas nicht stimmt und sogar wo der Fehler liegt.

[haentschman]

Moin...

Um diese Uhrzeit (ohne Kaffe) ist das mit dem Denken schlecht. Dann zeigt mir mal, wie es richtig geht.

Stichworte:
- nicht Typlos
- in der Klasse aber ohne class (Zugriff auf private Felder)
- ohne Context Objekt

Danke...

[jaenicke]

Statt sich mit Pointern und Methodenreferenzen herumzuärgern würde ich schlicht Interfaces benutzen. Dann übergibst du der DLL einfach nur dieses Interface und kannst dann aus der DLL dein Objekt in der Hostanwendung ganz normal über Methoden, Properties usw. ansprechen.

[Zacherl]

Zitat von jaenicke:

Statt sich mit Pointern und Methodenreferenzen herumzuärgern würde ich schlicht Interfaces benutzen. Dann übergibst du der DLL einfach nur dieses Interface und kannst dann aus der DLL dein Objekt in der Hostanwendung ganz normal über Methoden, Properties usw. ansprechen.

Wäre auf jeden Fall kein schlechter Ansatz und wenn man tatsächlich auf einen Context-Parameter verzichten will auch die einzige saubere Lösung.

Zur Typsicherheit:

Delphi-Quellcode:

type
  TMyCallback = procedure(Context: Pointer; P1, P2: PWideChar); stdcall;

..

procedure SetCallback(Callback: TMyCallback; Context: Pointer); // <- TMyCallback statt Pointer

Ich persönlich bin ein wenig von C-APIs (insbesondere der WinAPI) beeinflusst, weshalb ich diese Art von Context-Parametern gewöhnt bin und sie auch recht gerne verwende. Den untypisierten Pointer-Typ kannst du an dieser Stelle auch ohne weiteres mit dem Typ deiner Klasse austauschen (nur im Programm, nicht in der Dll), wenn du dich damit sicherer fühlst.

Delphi-Quellcode:

type
  TMyCallback = procedure(Instance: TMyCallbackClass; P1, P2: PWideChar); stdcall;

..

procedure SetCallback(Callback: TMyCallback; Instance: TMyCallbackClass);

[himitsu]

Zitat von Zacherl:

Ich persönlich bin ein wenig von C-APIs (insbesondere der WinAPI) beeinflusst, weshalb ich diese Art von Context-Parametern gewöhnt bin und sie auch recht gerne verwende. Den untypisierten Pointer-Typ kannst du an dieser Stelle auch ohne weiteres mit dem Typ deiner Klasse austauschen (nur im Programm, nicht in der Dll), wenn du dich damit sicherer fühlst.

Aber nicht bei Schnittstellen zu DLLs, zumindestens nicht mit Klassen und vorallem nicht ohne gegen die RTL (Laufzeitpackages) zu linken,
denn so klappt mit der RTTI und gemeinsamen Ressourcen garnichts, was bei Klassen aber zwingend nötig ist.

[Zacherl]

Zitat von himitsu:

Zitat von Zacherl:

Ich persönlich bin ein wenig von C-APIs (insbesondere der WinAPI) beeinflusst, weshalb ich diese Art von Context-Parametern gewöhnt bin und sie auch recht gerne verwende. Den untypisierten Pointer-Typ kannst du an dieser Stelle auch ohne weiteres mit dem Typ deiner Klasse austauschen (nur im Programm, nicht in der Dll), wenn du dich damit sicherer fühlst.

Aber nicht bei Schnittstellen zu DLLs, zumindestens nicht mit Klassen und vorallem nicht ohne gegen die RTL (Laufzeitpackages) zu linken,
denn so klappt mit der RTTI und gemeinsamen Ressourcen garnichts, was bei Klassen aber zwingend nötig ist.

Sollte doch eigentlich in jedem Falle funktionieren Innerhalb der Dll wird ja nicht mit der Klasseninstanz gearbeitet. Dort kommt sie als untypisierter Pointer rein und wird als Solcher auch wieder an die Callback Funktion übergeben. Sehe jetzt nicht, wo es da Probleme geben könnte.