also das ist die fortführung von meinem andrem thread (www.auq.de/viewtopic.php?t=1168) denn da hat das nicht mehr reingepasst, war wohl doch nicht so einfach wie ich dachte...

also es soll volgendermaßen sein

Programm 1 (das hauptprogramm)
Programm 2 (ein plugin für das hauptprogramm)

1- Programm 1 ist gestartet,
2- User Startet das Plugin aus Programm 1
3- Programm 2 das Plugin macht einen Reqest ob Programm 1 da ist und auch arbeiten kann
4- Programm 1 anwortet positiv
5- Programm 2 erhält die antwort

(Okay soweit geht alles, nur jetzts gibts probleme)

6- Programm 2 erfragt darauf das momentane verzeichnis von Programm 1
7- Programm 1 erhält request und SOLLTE das verzeichnis übermitteln
8- Programm 2 erhält antwort und hat das verzeichnis (schön währe es )

okay soweit so gut... ich hoffe ihr könnt mir da weilterhelfen...

Ist dein Plugin tatsächlich eine Eigenständige EXe oder ist es ein DLL, BPL oder etwas ähnliches?

ja also das plugin ist ein eigenständiges programm

zero hat folgendes geschrieben:

ja also das plugin ist ein eigenständiges programm

Warum benutzt du denn keine DLL? So könnntest du diese komplette, eigentlich überflüssige Arbeit sparen.

Ich kann mir eigentlich kein Programm vorstellen das aus zwei ausführbaren Teilen bestehen müsste. Außerdem kannst du Programm 2 ja ohne Programm 1 nicht nutzten. Das macht das verwenden einer DLL noch sinnvoller.

Tobias

also DLL's kommen nicht in frage, die sind eifach *mist*e... zumal ich kein bock habe irgendwelche borland librarys mitzuliefern, wirst ja wohl auch wissen wieso wenn du schonmal dlls geschreiben hast.

und dazu kann man das programm (plugin) auch ohne die hauptanwendung nutzen muss nur den path als parameter angeben ist aber etwas nervig...

aber trozdem danke für den vorschlag

und wollte schon das so durchführen wie ich es mir gedacht habe, das die programme untereinander komunizieren, kann man ja immer mal gebrauchen

habe aber auch schon gelesen das messages nicht so für datenkomunikation unter programmen geeignet sind... sollte man eher DDE oder sowas nehmen... hab ich aber nicht so die ahnung von, hat da wer einige samples oder so ? währe ich auch dankbar für

zero hat folgendes geschrieben:

also DLL's kommen nicht in frage, die sind eifach sch***e... zumal ich kein bock habe irgendwelche borland librarys mitzuliefern, wirst ja wohl auch wissen wieso wenn du schonmal dlls geschreiben hast.

Hm. Wenn man ein paar Grundsätze beachtet sollte man nicht unbedingt irendwie Librarys mitgeben. Bei mir jedenfalls geht es ohne.

Zitat:

aber trozdem danke für den vorschlag

Bitte Bitte

Zitat:

und wollte schon das so durchführen wie ich es mir gedacht habe, das die programme untereinander komunizieren, kann man ja immer mal gebrauchen

Wenn es wirklich nur um Pfade etc. geht - warum nutzt du nicht einfach die Registry die dann von P2 ausgelesen wird. Da P2 auch ohne P1 läuft kann es sich ja nicht um viel mehr handeln [/quote]

Zitat:

... sollte man eher DDE oder sowas nehmen...

Wenn ich mich jetzt nicht ganz Irre räd MS von der Verwendung von DDE ab. Außerdem ist es veraltet und hat angeblich nie richtig funktioniert. (Habe noch nie damit gearbeitet deswegen "angeblich" )

Mich würde mal interessieren was du da vor hast. Irgendwie kann ich den Sinn der Kommunikation noch nicht ganz entdecken. Es sieht mehr so als ob du es dir unnötig kompliziert machst.

Tobias

Da es sich nur um einen einfachen String (einen Pfad) handelt wäre eine Kommunikation mit WM_COPYDATA wahrscheinlich am naheliegensten! Alles andere wären die berühmten "Kanonen auf Spatzen". Über die Funktionalität mit WM_COPYDATA gibts nen Tipp von mir bei www.swissdelphicenter.ch (prozessübergreifende Kommunikation mit WM_COPYDATA oder so ähnlich heißt er).

Was die zwei Programme betrifft... eine DLL wäre wahrscheinlich wirklich geeigneter, wobei es manchmal auch praktischer sein kann bestimmte Opertaionen in einen eigenen Prozess auszulagern.. das liegt dann an dir.

Zu dem zweiten Prozess fallt mir noch eine Möglichkeit zur prozessübergreifenden Kommunikation ein -> MMF (Memory Mapped Files)
Sofern der 2te Prozess (das PlugIn) vom 1ten Prozess abgespaltet wird kann dieser das MMF-Kernel-Objekt an den 2ten Prozess vererben so dass dieser Zugang zu demselben MMF hat wodurch dann ebenfalls wieder Kommunikation über Prozessgrenzen hinweg möglich ist.

MMFs sind übrigens "low-level Kommunikation" und alle anderen lokalen Inter-Prozess Kommunikationen basieren auf MMFs.

@t-ob-i

also das projekt ist ein Inventarmanager für kleine bis mittle firmen (ist sogar schon im test ) die plugins vereinfachen halt nur einige sachen und sollen extern sein damit das programm auch nicht so umfangreich und unübersichtlich wird (momentane build größe 1,09MB und über 2500 zeilen source... irgendwann sollte mal schluss sein ).

@Motzi

naja es würde bestimmt nicht nur bei ein paar kleinen strings bleiben sonder auch mal um ganze strucs / records.

zu den dlls, naja die währen dann so sehr an das programm gebunden sollte auch nicht sein...


das problem ist eigentlich nur:
PROGRAMM 1 <-DATEN-> PROGRAMM 2
die programmen sollten untereinander komunizieren können ohne irgendwelche datein anzulegen oder sowas... ist irgendwie arm... das muss ja auch anders gehen !?

WM_COPYDATA kann auch mit Records eingesetzt werden. Die Sache wird dann zwar etwas komplizierter, funktioniert aber auch. Sobald der Datenverkehr zwischen den beiden Prozessen aber etwas höher sein sollte würde ich mich nach Alternativen umsehen. Da gibts zB COM (die wahrscheinlich effektivste Methode, aber auch die auwändigste), Mailslots, Pipes, RPC und Windos Sockets

Aber wie gesagt basieren diese Methoden alle auf MMF. Du brauchst das also alles nicht sondern kannst alles über MMF selbst machen. Du kannst MMF auf 2 verschiedene Arten verwenden. Entweder du erzeugst ein MMF als Abbild einer Datei auf der Festplatte (in deinem Fall eher ungeeignet) oder aber du lasst Windows das MMF auf einen Bereich der Swap-Datei abbilden. Im 2ten Fall musst du also keine Datei anlegen, sondern Windows stellt den physischen Speicher für das MMF als Teil der Swap-Datei zur Verfügung. Ich glaube diese Methode wäre dann wohl am besten geeignet.

und für die erstenPunkte 1-5 könnte Programm 1 auch einfach ein MUTEX erstellen (CreateMutex) und Programm 2 probiert das gleiche, wenn es den Fehler ERROR_ALREADY_EXISTS bekommt, dann ist programm 1 aktive und bereit