Welche Daten zwischen Plugin Anwendung?

[gsh]

Das ist ja alles viel zu komplitziert außerdem geht SharMem nur mit delphi oder?

Wenn ich sage schau in der CodeLib vorbei dann mein ich des auch so, denn die Callback funktion hab ich dort auch beschrieben ... schau dir "PluginSend : procedure(Befehl : PChar; Parameter : Pointer);" genau an. Das ist nämlich die Callback funktion.

[Der_Unwissende]

@gsh Bleib doch ein wenig ruhig. Ich glaube er hat schon in der CodeLib vorbei geschaut. Ist ja auch anzuerkennen, dass du da das Trillian Plugin-System nachgebildet hast, aber es ist nicht der einzigste Weg und sicherlich nicht der optimale (von dem ich auch nicht weiß wie er Aussieht, aber es geht in der Regel immer irgendwie besser!). Gerade weil du übermässig viel Flexibilität anbietest, lässt sich das leicht sagen, es gibt Fälle da möchte man nicht soviel Flexibilität anbieten (oder hat auch nicht die Perfomance und Ähnliches).
Ich finde dein Kommentar gerade wirkt leicht aggressiv. Ist nur eine Meinung (ich weiß ich schreib auch nicht immer freundlich). Aber hab doch keine Sorge, dass keiner deinen CodeLib Beitrag liest oder was auch immer. Du hast ja schon gesagt dass da was steht und jeder der diese Lösung möchte wird sie schon finden.

[gsh]

sry wenn ich ein bisschen aggresiv gerwirkt habe

Ich wollte damit auch nicht auf mein felxibles pluginsystem hinweissen sondern die auch darin enthaltene Callback funktion
Somit kann er die Prozedure in der DLL aufrufen und in der Anwendung wird sie dann ausgeführt.

[Der_Unwissende]

Also ich persönlich würde hier ehrlich gesagt weiterhin zum Observer-Pattern raten. Sowohl das PlugIn als auch die Klasse, die das PlugIn aufnimmt können ja dabei Observable sein. Ein Observable muss dabei nur zulassen, dass sich Listener für ein bestimmtes Ereignis registrieren können (und derigistrieren).
Im einfachsten Fall ist das einfach ein Ereignis, bei dem ein Stream übergeben wird (ein Array von Byte ist schließlich sehr flexibel). Da das PlugIn irgendwann initialisiert/gefunden/bekannt gemacht werden muss, ist diese Stelle auch ideal dafür geeignet. Hier kann dann die eigentliche Klasse sich beim PlugIn als Listener registrieren und umgekehrt.
Es entspricht natürlich in gewisser Weise der Idee einer Callback-Funktion, ich denke es ist aber etwas mehr OO (und irgendwo haben die DesignPattern ja nun auch ihren Sinn!).

Natürlich funktionieren auch ohne Frage alle anderen Wege, welcher einem am besten gefällt wird wohl eher Geschmackssache sein.

[Flippo]

hmmm nochmal so als frage... sind meine Dlls immer im selben "Adressraum" wie meine Hauptanwendung? Hab da keine Ahnung was das ist...

und ist das die WM_COPYDATA Message-ID, die dazu führt, dass ich die böse SharedMemory erzeuge?

[jbg]

Zitat von Flippo:

sind meine Dlls immer im selben "Adressraum" wie meine Hauptanwendung?

Ja.

Solltest du aber DLL-injection oder Hook-Techniken benutzen (was ich durch deine Frage erstmal bezweifle), dann sieht das anders aus. Dort gelten andere Regeln.

[rage2001]

Hey Flippo

Danke für Deinen Tip. Daran hatte ich garnicht gedacht. Zumal ich anderen Programmen diesen Weg auch schon ermöglicht habe. Man manchmal ist man ja auch mit Blindheit geschlagen.
Und um hier jeder Diskussion aus dem Wege zu gehen, eine kurze Erklärung
>Die Plugins werden von meinem Programm unterstützt wie das allgemein auch üblich ist.
>Zusätzlich hatte ein paar Firmen sich gewünscht ohne großen Brimporium und Umstelleung der Sourcen Ihrer Programm ein Zugriff auf das USB-Display zu erhalten und diesen Programmierern habe ich ebend diesen Weg per WM_COPYDATA ermöglicht. Und alle Beteiligten sind damit zufrieden.
An alle anderen aus diesem Thread vielen Dank für die Tips und Anregungen. Es ist wie immer, viele Wege führen nach Rom.