DLL Callback Pointerübergabe erwartet Variable

[Cyberaxx]

Delphi-Quellcode:

function TMC_Plugins.Add: TMC_Plugin;
begin
  Result := inherited Add as TMC_Plugin;
end;

Was da nun weiß ich nicht aber ich denke mal es wird eines zurück geliefert.

Generelle Frage, ist denn der Part der bei mir die AV auslöst denn soweit in Ordnung?
Das hat mir im Moment wieder die Lust auf mein MediaCenter verdorben, das ich schon wieder an sowas kleinem scheiter...

Die gemeinsame Unit

Delphi-Quellcode:

type
  TPlugData = packed record
    PluginType: Integer;
    PluginCanConfig: Boolean;
    PluginName: PChar;
    PluginAuthor: PChar;
    PluginVersion: PChar;
  end;
  TPPlugData = ^TPlugData;

type
  TPluginData = procedure(PPlugData: TPPlugData); stdcall;

Meine Main App

Delphi-Quellcode:

[...]
Lib: THandle
PluginData: TPluginData;
[...]
procedure TForm1.Btn_LoadClick(Sender: TObject);
begin
  if Opendialog.Execute then begin
    Lib := LoadLibrary(PChar(OpenDialog.FileName));

    if Lib = 0 then
      ShowMessage('Plugin konnte nicht geladen werden!');

    @PluginData := GetProcAddress(Lib, 'PluginData');
    PluginData(@PlugData);
[...]

In der DLL

Delphi-Quellcode:

[...]
procedure PluginData(PPlugData: TPPlugData);
begin
  PPlugData^.PluginType := INIT_READ;
  PPlugData^.PluginCanConfig := True;
  PPlugData^.PluginName := 'Media Center TestPlugin';
  PPlugData^.PluginAuthor := 'dsn';
  PPlugData^.PluginVersion := '1.0.0';
end;
[...]
exports
  SetCallBack, ReceiveData, Start, Stop, Configure, PluginData;

[Apollonius]

Arg. Lass dir mal MC_Plugins.ItemClass.ClassName ausgeben.

[edit]Oh, ich habe gerade den as-Cast gesehen. Da hast du ItemClass wohl irgendwo schon richtig umgestellt.[/edit]

[Cyberaxx]

Zitat:

---------------------------
Testanwendung
---------------------------
TMC_Plugin
---------------------------
OK
---------------------------

[Muetze1]

Kleiner Vorschlag. Damit sparst du dir das @ und die anderen Verrenkungen und du bist typensicherer:

Delphi-Quellcode:

type
  TPlugData = packed record
    PluginType: Integer;
    PluginCanConfig: Boolean;
    PluginName: PChar;
    PluginAuthor: PChar;
    PluginVersion: PChar;
  end;

type
  TPluginData = procedure(var PlugData: TPlugData); stdcall;

[Cyberaxx]

Finde gerade den Post / das Forum nicht mehr...

Dazu gab es ein Beispiel Projekt wie man Records und Objekte mit DLLs nutzen kann, die dann auch C Conform sind.
Was für mich doch recht wichtig ist. :)
Daran hatte ich mich gehalten darum diese Umstände.

Wenn es aber auch auf die normale Art geht, mach ich das auch gerne so :)

[Cyberaxx]

Sicherlich wird jeder der diesen Post liest anfangen laut über mich zu lachen...

Nachdem ich die DLLs neu kompiliert habe, funktioniert es.
Hat denn jemand eine Ahnung wo der Unterschied liegt zwischen der normalen Lade Prozedur und der Lade Prozedur mit der Collection?

Ich glaube ich sollte die Finger von der Plugin programmierung lassen...

[Cyberaxx]

Ich dachte ich kann es nicht schlimmer machen aber zack da kommt wieder nen Prob, wieder gleicher Record...

Ich habe nun versucht alles in eine eigene Klasse zu verpacken "TMCP_Manager", da es ja nun so klappt wie es soll.
Dabei kommt nun wieder der die AV und ich kann wieder nicht auf meine Komponenten zugreifen.
Was ist das für eine ....?

Tausche ich das Record gegen einen einfachen PChar als Rückgabewert aus klappt es, er hat wirklich nur Probleme mit dem Record auf das ich allerdings zugreiffen kann...

Habe mal den Source angehängt, vllt. traut sich ja jemand mal darüber zu schauen.
Es gibt die Hauptanwendung und zwei Plugins, einer ist ein reiner Testplugin und der andere nutzt den IO-Warrior.

Zu erwarten ist aber nicht viel, da es nur zum testen ist.

Wäre eigentlich toll wenn ich das so nutzen könnte wie ich es gerne würde. Da soll noch ne Menge hinter sitzen.

[Muetze1]

Du gibst temporäre Strings zurück. Diese sind nach verlassen der Procedure natürlich nicht mehr gültig und verlieren damit meist ihren Inhalt, da deren Speicher wieder verwendet wird.

Eine Möglichkeit: Konstanten definieren und das Plugin verweist auf diese:

Delphi-Quellcode:

// 1. Möglichkeit: const

const
  coPIName = 'IO-Warrior 24';
  coPIAuthor = 'dsn';
  coPIVersion = '0.9.0';

procedure PluginData(var PlugData: TPlugData); stdcall;
begin
  PlugData.PluginType := INIT_READ;
  PlugData.PluginName := @coPIName;     // das sind temporäre Variablen!
  PlugData.PluginAuthor := @coPIAuthor;
  PlugData.PluginVersion := @coPIVersion;
end;

Andere Möglichkeit: der Aufrufer besorgt vor dem Aufruf Speicher und übergibt diesen an die DLL. Sprich: Der Aufrufer muss (z.B. 41 Bytes) an Speicherplatz reservieren und gibt die Zeiger auf diesen Speicherplatz an vor dem Aufruf. Die DLL kopiert dann die Zeichenketten entsprechend in den zur Verfügung gestellten Speicher.

Delphi-Quellcode:

// 2. Möglichkeit: caller stellt Speicherplatz in den PChar's zur Verfügung
//                  und du füllst den entsprechend 

procedure PluginData(var PlugData: TPlugData); stdcall;
begin
  PlugData.PluginType := INIT_READ;
  StrPLCopy(PlugData.PluginName, coPIName, 40); // 40 = bytes die der Aufrufer zur Verfügung stellt
  StrPLCopy(PlugData.PluginAuthor, coPIAuthor, 40); // 40 = bytes die der Aufrufer zur Verfügung stellt
  StrPLCopy(PlugData.PluginVersion, coPIVersion, 40); // 40 = bytes die der Aufrufer zur Verfügung stellt
end;

Und da die bösen Pufferüberlaufe auch in Delphi entstehen können, nutzen wir eine Funktion um dies zu verhindern.

[Cyberaxx]

Ja das klingt logisch aber warum funktioniert es dann wenn ich es so laufen lasse immer?

Ich dachte das hätte ich ja "gelößt" indem ich ja direkt von der Main App in das Record schreiben lasse, ich übergebe doch den Pointer auf den Record? Dieser sollte doch noch erhalten sein, da er aus der Main App kommt oder irre ich mich da?

Wie würde es zudem aussehen wenn ich den Record als Result einer Funktion zurück gebe, macht das nen Unterschied?

[Muetze1]

Zitat:

Zitat von Cyberaxx

Ja das klingt logisch aber warum funktioniert es dann wenn ich es so laufen lasse immer?

Zufall, weil der temporäre Speicher noch nicht überschrieben wurde?

Zitat:

Zitat von Cyberaxx

Ich dachte das hätte ich ja "gelößt" indem ich ja direkt von der Main App in das Record schreiben lasse, ich übergebe doch den Pointer auf den Record?

Der Record ist nicht das Problem (der Var-Typ sorgt auch dafür, dass es ein Pointer ist, von daher bevorzuge ich die var Methode) - aber die PChars in den Record sind das Problem. Das sind Zeiger auf die Zeichenketten. Und diese müssen irgendwo alloziiert werden.

Zitat:

Zitat von Cyberaxx

Dieser sollte doch noch erhalten sein, da er aus der Main App kommt oder irre ich mich da?

Die PChars sind nur Zeiger und im Idealfall nil.

Zitat:

Zitat von Cyberaxx

Wie würde es zudem aussehen wenn ich den Record als Result einer Funktion zurück gebe, macht das nen Unterschied?

Dort würde dann die DLL den Speicher für den Record alloziieren und die App freigeben. Das wären dann auch wieder zwei unterschiedliche Speichermanager. Aber auch diese Lösung löst nicht das Hauptproblem mit den PChar's.