Probleme mit WM_CopyData

[Luckie]

Zitat von p80286:

weil Pchar auf 16Bit Char zeigt (D2010). Nimm Pansichar und es klappt wieder.

Früher wurde immer nach Unicode Unterstützung geschrien. Jetzt ist sie da und jetzt gibt es immer wieder die Ratschläge alles wieder auf Ansi zurückzustutzen.

[p80286]

Entweder man arbeitet mit Ansichar (8Bit) oder mit Char (16Bit)aber das sollte man dann auch sauber durchziehen.
Und wenn es eine saubere Typbezeichnung gäbe, wie z.B. Char8 oder Char16 dann würden sich auch viele nicht so schwertun.
Aber ich glaube das hatten wir hier schon alles einmal.

Gruß
K-H

[DeddyH]

Zitat von p80286:

Char (16Bit)

Char ist entweder 8 oder 16 Bit, je nach Delphi-Version. Und explizite Typbezeichnungen gibt es auch, nämlich AnsiChar und WideChar. Alles kein Problem, solange man nicht davon ausgeht, dass die Bytegröße eines Strings seiner Länge entspricht, was ja hier der Fall war.

[Bernhard Geyer]

Bedenke auch das eine WM_COPYDATA im eigenen Programm zur Kommunikation Programmintern nicht funktioniert bzw. zufällig funktioniert wenn NView installiert ist. Dieser Hook WM_COPYDATA-Events und reicht sie nicht mehr weiter wenn das Event nicht zwischen Prozessen verwendet wird.

[himitsu]

Wobei PAnsiChar kein sooo schlechter Rat war.

Aber ich würde da eher auf PWideChar gehn.

Also WideString/UnicodeString, SizeOf(WideChar) und PWideChar.

Denn wenn man jetzt ein altes Ansi-Programm mit einem neuen Unicode-Programm reden läßt, dann kommt wieder nur Müll raus.


Beim Abspeichern und beim Datenübertragen niemals dynamisch Typen ala Integer, NativeInt, Pointer, String, PChar und Char verwenden (außer man speichert die Größe mit ab),
denn dabei kann man schnell Probleme bekommen, wenn sich diese Typen mal ändern. (siehe "früher ging es mal")



PS: Auch aufpassen, wen die beiden Programme mit unterschiedlichen Rechten arbeiten.
Ein Programm im Benutzerkontekt kann einem Programm mit höheren Rechten (Admin) keine Messages schicken.

[DeddyH]

Sender- und Empfänger-Programm sind ja wohl laut Ausgangspost beide vom TE. Solange er also in beiden die selben Typen (und dieselbe Delphi-Version) benutzt, sollte es bezüglich Ansi oder Unicode keine Probleme geben.

[himitsu]

Mir ist auch grade aufgefallen, daß hier Pointer nach LongInt (32-Bit) gecastet werden.
Da kann es in einem 64 Bit-Programm natürlich auch wunderbar knallen.
In Win64 sind zwar viele Handle immernoch 32 Bit, auch wenn der Typ 64 Bit ist, als Tribut an die IPC zu 32 Bit, aber Zeiger aus dem Delphi-Speichermanager sind da natürlich nicht begrenzt, außer es wird explizit so verlangt.

PS: Für SendMessage gibt es auch extra die zugehörigen Typen, also WPARAM, LPARAM und LRESULT.

[Blup]

Bei unterschiedlichen Prozessen ist die Adresse nur so lange gültig, bis die Nachricht verarbeitet wurde.
An dieser Stelle muss ein neuer String mit einer Kopie der Zeichenkette angelegt werden:

Delphi-Quellcode:

..
s := PChar(Msg.CopyDataStruct.lpData);
..

Der zusätzlichen Cast auf String ist ungültig, denn lpData verweist nur auf einen Puffer mit einer 0-terminierten Zeichenkette.
Bei einem String liegt ein Teil der Daten (z.B. Referenzzähler) vor dieser Adresse.