Eigenes Plugin kann nicht auf Applikation zugreifen...

[torud]

Hallo Wissende!

Angeregt durch einige Tutorials und der Notwendigkeit meine Applikation modular aufzubauen, habe ich versucht ein eigenes Plugin zu erstellen, welches sich um den Datenexport kümmern soll. Damit Ihr mir helfen könnt noch folgendes:

Meine Daten halte ich in einer Access-DB, welche ich mit einem Datenmodul (DM) verwalte. Da ich es nicht besser weiss, habe ich dem Plugin als Uses dieses Datenmodul hinzufgefügt. Dadurch wird es natürlich gleich mal 1,2MB gross. Ich bekomme danach auch die Syntaxvorschläge für diese Form(DM), aber sobald ich auf dem Plugin einen Button betätige, der die AdoConnection vom Datenmodul holen soll, erhalten ich eine nicht definierbare Fehlermeldung.

    ADOTable1.Connection:=dm.ADOConnection1;
Zugriffsverletzung bei Adresse 019D8D8B in Modul 'Export.dll'. Lesen von Adresse 00000060.

Ich weiss nun nicht, was ich falsch mache, oder wie ich es besser machen könnte...

Wer kann helfen?

[tommie-lie]

Benutze eine Methode wie "GetDataConnectionWasWeissIch()", die dir das Objekt für den Datenzugriff zurückgibt im Modulinterface. Dann könnte jedes Modul, daß sich an dieses Interface hält, dieses Datenobjekt beschaffen und damit arbeiten. Da es um Objekte geht, wäre es vielleicht auch sicherer, BPLs zu benutzen. Für die Rückgabe muss natürlich dein Hauptprogramm sorgen, daß dann das benutzte Datenobjekt zurückgibt. Und weil's ein Objekt ist, ist's das gleiche wie das, was auch im Hauptprogramm verwendet wird.

[torud]

Leider verstehe ich das nicht genz!
Was ist denn daran anders, als das Obejkt direkt anzusprechen?

Und wie könnte ich das machen?
Müsste ich das nicht irgendwie public oder über exports machen?

Sorry, aber mein Wissen über dieses Thema hält sich doch sehr in Grenzen...

[shmia]

Zitat von torud:

Meine Daten halte ich in einer Access-DB, welche ich mit einem Datenmodul (DM) verwalte. Da ich es nicht besser weiss, habe ich dem Plugin als Uses dieses Datenmodul hinzufgefügt. Dadurch wird es natürlich gleich mal 1,2MB gross. Ich bekomme danach auch die Syntaxvorschläge für diese Form(DM), aber sobald ich auf dem Plugin einen Button betätige, der die AdoConnection vom Datenmodul holen soll, erhalten ich eine nicht definierbare Fehlermeldung.

Das ist schon die Ursache für deine Probleme.
Die Variable (namems DM), die den Zeiger auf dein Datenmodul enthält gibt es 2-mal:
einmal im Hauptprogramm und einmal im Plugin.
Jetzt müsstest du den Inhalt von DM vom Hauptprogramm auf die Variable im Plugin übertragen:

Delphi-Quellcode:

// procedure im Plugin, wird vom Hauptprog aufgerufen
procedure SetDataModule(value:TComponent);
begin
   dm := value;
end;

[torud]

Hallo Shmia!

Leider war es das auch nicht!

Die Typen sind nicht kompatibel TDM und TComponent!

Stell ich mich denn so dumm an, oder ist es wirklich so schwer ein Plugin und eine Kommunikation zwischen beiden herzustellen???

Könnte mir jemand zeigen, erläutern, wie ich gaanz einfach mit einem Hauptform einem Plugin einen PChar übergebe, das Plugin anzeige und dort dann in einem Label den übergebenen Wert anzeige???

Ich glaube, dass ich es dann besser verstehe...

[DGL-luke]

mit

dm := (value as TDM)

in shmias funktion sollte es gehen

[torud]

Habe es nun so abgeändert und auch die Prozedur mit stdcall; versehen und in export eingetragen:

Delphi-Quellcode:

procedure SetDataModule(value:TComponent);  stdcall;
begin
   dm := (value as TDM)
end;

Wenn ich nun auf meinem Hauptform einen Button platziere und dort diesen Code hier aufrufe:

Delphi-Quellcode:

procedure TForm1.ToolButton2Click(Sender: TObject);
begin
    SetDataModule(datamodul);
end;

schreit der Compiler, dass SetDataModule undefiniert ist, dabei habe ich doch hier den Code publiziert. Ist das wieder falsch?

Delphi-Quellcode:

type
  TMenuCaption = function(pStr: PChar; iStrLen: Integer): Integer; stdcall;
  TLoadPlugin = procedure; stdcall;
  TSetDataModule = procedure; stdcall;

Scheint nicht mein Tag zu sein, aber danke für Eure Mühe...

[choose]

Hallo torud,

ich rate von Ansätzen der Art

Delphi-Quellcode:

procedure SetDataModule(ADataModule:TMyVerySpecialDataModule);
begin
   MyVerySpecialDataModule := ADataModule;
end;

zugunsten einer minimalen Schnittstelle einer möglichst losen Kopplung und dem Geheimnisprinzip sowie aller sich daraus ergebenen Folgen wie bessere Testbarkeit, Wartbarkeit, Erweiterbarkeit, Wiederverwendbarkeit, etc. ab.

Das Thema Plug-ins ist relativ komplex und umfangreicher, als das Einbinden schlichter DLLs oder BPLs. Darüber hinaus macht der Mehraufwand nur dann Sinn, wenn Du davon ausgehen kannst, dass auch nach der Auslieferung Deiner Hauptanwendung Änderungen hinter einer immer festen Schnittstelle vorkommen werden (das schließt nach Deinem Ansatz die Unveränderlichkeit des Datenmoduls ein!) und eine erneute Auslieferung der Anwendung (oder einzelner DLLs) nicht rechtfertigen bzw. nicht möglich ist oder durch Dritte geschieht.
Um eine gute Modularität Deiner Applikation zu erreichen können Units, Klassen oder auch Verbünde in Form von speziellen Entwurfsmustern helfen, auch ohne dass Plug-ins notwendig sind.

Wenn Du dennoch Deine Lösung mit Delphi und Plug-ins realisieren möchtest, hilft Dir vielleicht das Produkt
Hydra von RemObjects oder der Beitrag "PlugIns in eigenen Anwendungen" von Sakura weiter.

[torud]

Hallo Choose!

Danke für Dein Info! Ich wollte eigentlich schon ein eigenes Plugin realisieren, denke aber, dass es wohl nichts wird, denn ich habe mir natürlich die beiden Tuts von Sakura vorgenommen und auch das von Luckie, konnte aber nicht wirklich vollends durchsteigen.

Es ist leider so, dass meistens einiges an Grundkenntnissen vorausgesetzt wird. Manchmal ist es einfach schrecklich nicht genug Wissen zu haben bzw. das, was andere schreiben zu verstehen. So gings mir bei Sakuras Tutorial! Es sah alles ganz toll aus, wie er das gemacht hat, aber leider verstehen konnte ich es nicht!

Und natürlich hast Du recht, dass es ein Plugin, so wie ich es vor habe, sich relativ unflexibel darstellt, wenn ich es mit einem Datenmodul verknüpfen will. Beides dürfte sich nicht ändern, damit immer alles im Lot bleibt. Aber davon gehe ich einfach mal aus.

Ich würde ja auch gern einen anderen Weg nutzen, aber ich will auf jeden Fall sicherstellen, dass ich gewisse Aufgaben, wie das Exportieren von Daten in deinem bestimmten Format, über ein zusätzliches Modul erledigt wird. Ich muss ja nicht alles in das Hauptform einbinden. Nur wie soll ich das realisieren, wenn ich dazu auch Forms benötige und das Ganze optional anbieten will?

Und die Lösung mit der externen Komponente kommt aus finanziellen nicht in Frage!

[shmia]

Zitat von torud:

Leider war es das auch nicht!

Die Typen sind nicht kompatibel TDM und TComponent!

Ups, ich habe den falschen Datentyp verwendet:

Delphi-Quellcode:

// procedure im Plugin, wird vom Hauptprog aufgerufen 
procedure SetDataModule(value:TDataModule); 
begin 
   dm := TDMxxx(value); // TDMxxx ist der Name deines Datenmoduls
end;

Zitat von torud:

Stell ich mich denn so dumm an, oder ist es wirklich so schwer ein Plugin und eine Kommunikation zwischen beiden herzustellen???

Ja, das ist gar nicht so einfach.

Es gibt mehrere Wege, um ein Plugin-Verhalten herzustellen:
* mit "normalen" DLLs, die dynamisch vom Hauptprog geladen werden und eine definierte prozedurale Schnittstelle haben

* mit dynamisch geladenen Packages mit objektorientierter Schnittstelle
(siehe: http://www.obsof.com/delphi_tips/DL613.html )
nur für Delphi und C++-Builder geeignet!

* mit Active-X Libraries; wenn nur die für Automatisierung erlaubten Datentypen verwendet werden, können Plugins auch mit anderen Programmiersprachen erstellt werden
Softwaretechnisch die sauberste Lösung (da für Plugin und Hauptprog Schnittstellen=Interface deklariert werden) aber auch am schwierigsten