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.
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