[NonVCL] Problem WndProc; Pointer mit Daten füllen

[Blup]

Zitat von Luckie:

Dort weißt du den Inhalt des WParam der AnsiString Variable Text zu.

Da WParam = 0, weist er der Variablen "Text" "StreamList.Names[0]" zu.

Zitat von Luckie:

Dann kopierst du den Text in den Parameter der WndProc. Zum einen macht das keinen Sinn. Und zum Anderen ist LParam vom Typ DWord. Es wird also mit der Zeichenkette nichts anfangen können.

Da LParam einen Zeiger auf die Variable StreamName beinhalted, überschreibt er so den Inhalt dieser Variable mit dem Inhalt aus "Text".

Edit:
So kann das aber nur innerhalb einer Anwendung funktionieren, da jede Anwendung ihren eigenen Adressraum hat.
Datenaustausch zwischen verschiedenen Anwendungen ist z.B. mit WM_COPYDATA möglich.

[NickelM]

@Blup: WParam wird manchmal als Index verwendet, falls er höher ist als 0. Bei 0 leg ich den Index anders fest, aber das ist nicht das Prob, da trotzdem die Variable Text gefüllt wird. Sonst hast du völlig Recht. Nach meiner Kenntniss sollte es funken, aber dies tut es ja nicht .

EDIT: Doffe Frage, kann es sein, das ich erst irgendwie meiner WndProc (z.b. dem Programm) Rechte geben muss um auf den Speicher von der DLL-Variable zuzugreifen? Anscheinend macht die normale WndProc noch irgendwas, um in den Speicherbereich von der Variablen schreiben zukönnen. Oder irre ich da?

[NickelM]

Das habe ich mir auch schon gedacht. Aber warum funkt dann SendMessageA(WindowH,WM_GETTEXT,50,Integer(@StreamName) ?
WindowH wird doch, wie ich Windows kenne, auch ein Pointer auf irgendein Speicher sein. Weil das liesst ja von der anderen Anwendung den Fenster-Titel aus. Oder liegt das in einer Art Globalen Windows Speicher?
Naja, ich versuch mal ob ich das mit WM_COPYDATA irgendwie hinbekomme, was ich möchte.
Würd mich troztdem interessieren warum die oben genannte Zeile funkt. Die müsste eigentlich ja dan auch nicht funktionieren.

[himitsu]

Njain, Handle haben nichts mit Pointern zu tun. (auch wenn einige weniger Handle aktuell intern als Pointer verwaltet werden, wie z.B. das Handle von geladenen Modulen, wie DLLs)

Stell die Handle eher als Index in einer Liste vor.

Bei Messages wie WM_TEXT haben die Parameter eine vorgegebene Funktion, bzw. ein definiertes Datenformat, welches Windows kennt.
Demnach kann Windows dort auch den entsprechenden Speicher kopieren, wenn er in ein anderes Programm rüber muß.
Bei WM_COPYDATA wird ebenfalls angegeben wie und wo Daten liegen und Windows kann sich ebenfalls um das Kopieren kümmern.

Ansonsten (vorallem bei eigenen Messages) kann man eben nur Integer übergeben.
Oder Anderes, welches als global eindeutiger Wert darin übergeben werden kann. (z.B. globale Handle)

[NickelM]

Hm...also gibt es keine Möglichkeit auser WM_COPYDATA, irgendeine Variable zuerzeugen, egal ob Handle oder Pointer, die ich per SendMessage von der Plugin-DLL an die Anwendung übergeben kann um dort wieder auf meine Daten, die ich irgendwo hinterlegt habe, von 2 verschiedene Anwendungen drauf zugreifen kann?
Ich hab schon viel von Pipes gehört usw. , aber wie gesagt nur gehört. Ob das damit geht, weis ich auch nicht. Hab grad nen bischen mit GlobalAlloc und VirtualAlloc getestet, auch bei GlobalAlloc, den Handle an die andere übergeben, kein Unterschied. Ich werde wohl schauen müssen, ob ich irgendwie eine MessageLoop mit einem "unsichtbaren" Fenster in der DLL erzeuge und hoffen, dass ich dan mit WM_COPYDATA die Daten rüberbekomme.

Gruß
NickelM

[himitsu]

'ne Pipe ist wie eine Datei ... also eine Art Dateihandle und da diese Prozessgebunden sind, müßtest du bei Übergabe dieses Handle klonen.
Da der Empfänger den Sender nicht kennt und der Kloner das Recht benitzten muß das gewünschte Handle überhaupt klonen zu dürfen, wäre es vermutlich einfacher das Handle gleich beim Sender zu klonen, passend für den Zielprozess.
Oder MMF (Memory Mapped Files).

Tipp: IPC wäre das Thema, worüber du dich informieren solltest.

[Bummi]

falls Du Dich mit Pipes beschäftigen möchtest gibt es von Russell nette freie Komponenten, ich habe sie allerdings mittlerweile massiv erweitert und angepasst, der einzige Links den ich auf die Schnelle finden konnte:

http://r3code.livejournal.com/117012.html
http://micksmix.wordpress.com/2011/0...it-for-delphi/

[Assarbad]

Zitat von NickelM:

EDIT: Doffe Frage, kann es sein, das ich erst irgendwie meiner WndProc (z.b. dem Programm) Rechte geben muss um auf den Speicher von der DLL-Variable zuzugreifen? Anscheinend macht die normale WndProc noch irgendwas, um in den Speicherbereich von der Variablen schreiben zukönnen. Oder irre ich da?

Nicht der DLL, aber dem Prozess der die DLL benutzt und im Endeffekt SendMessage aufruft. Seit Vista gibt es da gewisse Mechanismen. Welches System verwendest du denn, gibt es 32/64bit-Schranken und vor allem laufen die Prozesse mit gleicher Privilegienstufe ("Elevation")?

Stichworte: UIPI (und ChangeWindowMessageFilterEx), Privilege Isolation, Integrity Levels

Zitat von NickelM:

Ich hab schon viel von Pipes gehört usw. , aber wie gesagt nur gehört. Ob das damit geht, weis ich auch nicht. Hab grad nen bischen mit GlobalAlloc und VirtualAlloc getestet, auch bei GlobalAlloc, den Handle an die andere übergeben, kein Unterschied.

Die funktionieren nur innerhalb des gleichen Prozesses. Ansonsten: VirtualAllocEx

Zitat von NickelM:

Ich werde wohl schauen müssen, ob ich irgendwie eine MessageLoop mit einem "unsichtbaren" Fenster in der DLL erzeuge und hoffen, dass ich dan mit WM_COPYDATA die Daten rüberbekomme.

Ich dachte die DLL schickt die Nachricht? Warum brauchst du dann eine Nachrichtenschleife in der DLL?

Ich wünschte mir, daß die "Generation Google" sich mal wieder in ein Problem verbeißen würde bis es gelöst ist, anstatt auszuweichen oder aufzugeben

[Luckie]

Zitat von Blup:

Da LParam einen Zeiger auf die Variable StreamName beinhalted, überschreibt er so den Inhalt dieser Variable mit dem Inhalt aus "Text".

Ja, OK, das stimmt. Aber mich verwirrt, was er damit erreichen will. Ich dachte er wollte an die Zeichenkette kommen, die auf die er im LParam einen Zeiger hat. Das Problem ist, um es noch mal deutlich zu machen, dass Zeiger nicht über Prozessgrenzen gültig sind. Es gibt ausnahmen. Bei WM_TEXT mapped Windows den Speicherbereich in einen Speicherbereich der für beide Prozesse gültig ist, so dass das mit den Zeigern funktioniert. Das sind noch Überbleibsel aus 16-Bit Windows Zeiten, als es noch keine getrennten Speicherbereiche gab. Bei WM_COPYDATA verfährt Windows ähnlich. Allerdings handelt es sich dabei um eine Fensternachricht, so dass zumindest der Empfänger ein Fenster sein muss. Ob auch der Thread von dem die Nachricht verschickt wird zu einem Fenster gehören muss, weiß ich jetzt nicht, aber man könnte es mal probieren, ob es auch ohne Fenster geht.

[Blup]

Die einfachste Lösung dürfte in diesem Fall die Übergabe der Zeichenkette per globaler Atomtabelle sein:
About Atom Tables