Mutex-Handling in DLL für zwei Programme

[TheSledgeHammer]

Zitat von peterbelow:

Die Deklaration ist falsch, die von der DLL exportierten Methoden sind nicht "of object"!
Mit deiner obigen Deklaration wird beim Aufruf ein zusätzlicher Parameter (Self) übergeben, den die DLL aber nicht erwartet. Das bringt den Call-Stack durcheinander.

Ok, danke für den Hinweis. Tatsächlich sollte ich mir die Direktive "of object" mal noch genauer zu Gemüte führen, denn dass das automatisch zu einem "self"-Parameter führt, war mir jetzt nicht bewusst. Da bliebe jetzt noch die Frage offen, weshalb das zwar für DLL-Funktionen weg bleiben muss, bei Funktionen, die innerhalb des Delphi-Programms ausgetauscht werden, aber nicht weg bleiben darf?! Da kommt dann nachher nämlich der Compiler-Fehler "Inkompatible Typen: 'Reguläre Prozedur und Methodenzeiger'".

Im Konkreten Fall deklariere ich sowas hier:

Delphi-Quellcode:

TErrCallback = procedure(const AMsg: string) of object;
FCallbackOnError: TErrCallback;

und belege die Variable FCallbackOnError dann mit der Prozedur:

Delphi-Quellcode:

// Deklaration
procedure ShowErrorMessage(const AMsg: string);
// Definition
procedure TFormClass.ShowErrorMessage(const AMsg: string);
begin
  MessageDlg(AMsg, mtError, [mbOK], -1);
end;

Edit
Hab meine Frage glaub selbst beantwortet. Unten aufgeführter Link gibt da das entsprechende Stichwort:

Code:

Ein Methodenzeiger wird in Form zweier Zeiger codiert, von denen der erste die Adresse der Methode speichert, während der zweite eine Referenz auf das Objekt enthält, zu dem die Methode gehört.

http://docwiki.embarcadero.com/RADSt...zedurale_Typen

[hoika]

Hallo,
sobald du eine Methode in einer Klasse hast, wird das Self beim Methodenaufruf immer mit übergeben.
Ist halt so.

Entweder deine Dll-Methoden (im Programm) sind nicht in einer Klasse,
oder du änderst die Prozeduren in der Dll -> neuer Parameter Dummy: TObject.

[Schokohase]

Man kann sich viel Ärger ersparen, wenn man das erheblich einfacher umsetzt.

Hier mal die DLL

Delphi-Quellcode:

library TheMutex;

{ Wichtiger Hinweis zur DLL-Speicherverwaltung: ShareMem muss die erste
  Unit in der USES-Klausel Ihrer Bibliothek UND in der USES-Klausel Ihres Projekts
  (wählen Sie 'Projekt-Quelltext anzeigen') sein, wenn Ihre DLL Prozeduren oder Funktionen
  exportiert, die Strings als Parameter oder Funktionsergebnisse übergeben. Dies
  gilt für alle Strings, die an oder von Ihrer DLL übergeben werden, auch für solche,
  die in Records und Klassen verschachtelt sind. ShareMem ist die Interface-Unit zur
  gemeinsamen BORLNDMM.DLL-Speicherverwaltung, die zusammen mit Ihrer DLL
  weitergegeben werden muss. Übergeben Sie String-Informationen mit PChar- oder ShortString-Parametern, um die Verwendung von BORLNDMM.DLL zu vermeiden.
 }

uses
  System.SysUtils,
  System.Classes,
  TheMutexImplementation in 'TheMutexImplementation.pas';

{$R *.res}

exports
  MutexAcquire,
  MutexRelease;

begin
end.

Delphi-Quellcode:

unit TheMutexImplementation;

interface

procedure MutexAcquire(); stdcall;
procedure MutexRelease(); stdcall;

implementation

uses
  System.SyncObjs,
  System.SysUtils;

var
  _Mutex: TMutex;

procedure MutexAcquire();
begin
  _Mutex.Acquire();
end;

procedure MutexRelease();
begin
  _Mutex.Release();
end;

initialization

_Mutex := TMutex.Create(nil, false, 'MyUniqueMutexName');

finalization

FreeAndNil(_Mutex);

end.

Und nun noch den benötigten Wrapper für die Dll

Delphi-Quellcode:

unit TheMutexWrapper;

interface

uses
  Winapi.Windows;

procedure MutexAcquire(); stdcall;
procedure MutexRelease(); stdcall;

const
  TheMutexDll = 'TheMutex.dll';

implementation

procedure MutexAcquire(); external TheMutexDll name 'MutexAcquire';
procedure MutexRelease(); external TheMutexDll name 'MutexRelease';

end.

[TheSledgeHammer]

Zitat von Schokohase:

Man kann sich viel Ärger ersparen, wenn man das erheblich einfacher umsetzt.

Sieh es mir bitte nach, aber DAS find ich beim besten Willen nicht einfacher Vielleicht "korrekter" aus programmiertechnischer Sicht, wenn es so etwas gibt. Ich mein, was hast du denn gemacht? Am Ende eine Unit erzeugt, die du mit initialization und finalization ausstatten konntest, sodass das Create und Free nicht in Funktionen gepackt werden muss. Wenn ich den Mutexnamen jetzt übergeben möchte, wird's allerdings schwierig und auch das Registrieren des Mutex kann ich nicht steuern damit. Und dynamisch laden wollt ich die DLL schon auch, also die "externals" wären an der Stelle für mich sowieso nicht gegangen; das kannst du aber natürlich nicht wissen, hatte ich auch nie erwähnt

Aber der Hinweis mit dem "of object" hat da tatsächlich geholfen, passt ja auch wunderbar zum Fehlerbild. Danke dafür, die jetzt anstehenden Tests werden es zeigen, aber sieht bisher ganz vielversprechend aus.

Zitat von hoika:

Entweder deine Dll-Methoden (im Programm) sind nicht in einer Klasse,
oder du änderst die Prozeduren in der Dll -> neuer Parameter Dummy: TObject.

Ja das mit dem Error-Callback war nicht in der DLL sondern das war ein Attribut einer anderen Klasse. Ich wollte damit auf den Unterschied zwischen DLL-Prozeduren und Klassen-Prozeduren hinaus, dass man beim ersteren kein "of object" verwenden darf und aber beim zweiten sogar verwenden muss. Der Grund ist mir wie gesagt ja jetzt klar