ListBox als TObject an Dll-PlugIn

[Unplugged]

Hallo,

ich versuche gerade, eine PlugIn-Schnittstelle zu konstruieren.
Allerdings im Moment noch ohne Interface's.

Die Kommunikation mit der Dll funktioniert auch, und bringt erstmal keine Probleme.
Ich habe zusätzlich in der Dll einen Eventhandler drin, den die Applikation beispielsweise bei einem
Klick aufruft. Speziell befindet sich in der Applikation eine TListBox, bei der die OnClick-Methode wie folgt genutzt wird:

Delphi-Quellcode:

procedure TForm1.ListBox1Click(Sender: TObject);
begin
  Self.RunEvent(evnClickItem, Sender);
end;

function TForm1.RunEvent(EventNotification: TEventNotification; Sender: TObject): Boolean;
//  ...
      if FPlugIns[I].PlugIn.EventHandler(EventNotification, Sender) = evnAbort then
//  ...
end;

In der Dll wird das Event wie folgt verarbeitet:

Delphi-Quellcode:

function TPlugTest.EventHandler(EventNotification: TEventNotification;
                                Sender: TObject): TEventAction;
Var
  ListBox1      : TListBox;
begin
  if ( EventNotification = evnClickItem ) then begin
    ListBox1 := TListBox(Sender);
    ListBox1.Items.Strings[ListBox1.ItemIndex] :=
        ListBox1.Items.Strings[ListBox1.ItemIndex] + '1';
  end;
  Result := evnOk;
end;

Wie man sieht, macht die Funktion nicht wirklich was sinnvolles, aber zu Demonstrationszwecken reicht es.

Was ist nun das Problem?!
Das ganze funktioniert leider nur 4 Mal. D.h. ich klicke zum Testen immer wieder auf das gleiche Element. Beim fünften Mal ( also 4 Einsen wurden schon angehangen ), kommt auf einmal eine Access Violation.

Jemand eine Idee, woran das Liegen kann ?

[Bernhard Geyer]

Beim austausch von Objekte zwischen Exe und DLL kommt es immer dann zu Problemen wenn keine gemeinsamen Laufzeitpackages verwendet werden, da dann sowohl Exe als auch DLL ein eigenes Objektmodell instanziieren und TObject der DLL <> TObject der Exe ist. Dies kracht sofort wenn man die Exe und die DLL mit unterschiedlichen Compilerversionen, unterschiedlichen Compileroptionen oder unterschiedlichen Versionen der Sourcen kompiliert.

[Unplugged]

Allerdings handelt es sich in dem Fall ja um den gleichen Compiler.
Zumal es ja auch erst nach einer Weile kracht, und nicht direkt beim ersten Mal.

Das ist halt die Sache, die ich im Moment nicht ganz verstehe.

[Robert_G]

Sorry, aber eine DLL, die Objekte exportiert ist doch witzlos.
Da du somit sowieso auf Delphi beschränkt bist, kannst du genausogut Packages nehmen.
So kannst du ganz easy Klassen, Interfaces und Funktion in deiner Anwendung aufrufen.

[Unplugged]

Darum geht es mir ja an der Stelle nicht. Das ganze soll ja später über Interfaces ablaufen.
Auf gut deutsch ist das nichts weiter als ein Test. Und logisch gesehen sollte dies ja auch so
funktionieren; unabhängig davon, wie effektiv das ist.

[Robert_G]

Nö, das ist viel krasses.
Schließlich musst du auf beiden Seiten ShareMem als MemoryManager nehmen, damit du überhaupt eine Chance hast, dass sich deine App nicht jede Sekunde in Wohlgefallen auflöst.
ShareMem ist aber bekannt dafür genau den gleichen Effekt zu haben.
Suche mal in den Borland NGS (Delphi.language.basm oder so ) nach dem FastMM.
Google könnte auch was finden: Fastcoder MM
Im Gegensatz zu Borlands buggy ShareMem ist es FastMM relativ egal welcher MM auf der anderen Seite (also deine APP) arbeitet.

[jbg]

Zitat von Robert_G:

Im Gegensatz zu Borlands buggy ShareMem

Also Delphi 1 bis 7 laufen mit dem ShareMem doch recht stabil. Und das Delphi 2005 da Probleme hat(te) liegt an was anderem.

Zitat:

ist es FastMM relativ egal welcher MM auf der anderen Seite (also deine APP) arbeitet.

Ist es nicht. Man muss in der EXE und DLL FastMM nutzen. FastMM braucht nur keine DLL, da es sich mit einen Speicherbereich reserviert, den der andere FastMM finden kann, und in dem die Daten stehen, wo der Speichermanager der EXE liegt (Addr(FastGetMem), Addr(FastFreeMem), Addr(FastReallocMem)).

[Bernhard Geyer]

Zitat von jbg:

Zitat von Robert_G:

Im Gegensatz zu Borlands buggy ShareMem

Also Delphi 1 bis 7 laufen mit dem ShareMem doch recht stabil. Und das Delphi 2005 da Probleme hat(te) liegt an was anderem.

Recht stabil ist gut gesagt. Für 98% der Anwendungen mag es genügen. Aber wird musten vor 2 Wochen wechseln da der Borland-Memory-Manager Speicherfrakmentierung aufgewiesen hat und trotzt nur 300 MB Speicherverbrauch im Taskmanger keine Speicher mehr der Anwendung geben konnte. Wir haben D6 mit allen Patches im Einsatz.
Und noch einen Vorteil hat FastMM. Es ist eine Memory-Checker eingebaut mit dem man sehr schnell Speicherlöcher oder genutzte Objekte nach der Freigabe erkennen kann. Außerdem ist er um einiges Schneller.

[jbg]

Zitat von Bernhard Geyer:

Und noch einen Vorteil hat FastMM. Es ist eine Memory-Checker eingebaut mit dem man sehr schnell Speicherlöcher oder genutzte Objekte nach der Freigabe erkennen kann. Außerdem ist er um einiges Schneller.

Das ist auch der Grund, warum ich den bei Delphi 6, Delphi 7, Delphi 2005 und bei meinen Programmen im Einsatz habe. Damit kann man D2k5 endlich mal (einigermaßen) geniesen.