Probleme mit WM_CopyData

[runningsoft]

Hallo,

warum funktioniert folgender, aus einem Tut abgeschriebener einfacher Code nicht? (Erzeugt mit Delphi 2010 auf Win7 64-bit)

Sender:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
var
  aCopyData: TCopyDataStruct;
  p: PChar;
begin
  p := 'String To send';

  with aCopyData do begin
    dwData := 0;
    cbData := StrLen(p) + 1;
    lpData := p;
  end;

  SendMessage(FindWindow('TFormRecv', nil), WM_COPYDATA, Longint(Handle),
              Longint(@aCopyData));
end;

Empfänger:

Delphi-Quellcode:

type
  TFormRecv = class(TForm)
    ListBox1: TListBox;
  private
    { Private-Deklarationen }
    procedure WMCopyData(var Msg: TWMCopyData); message WM_COPYDATA;
  public
    { Public-Deklarationen }
  end;

var
  FormRecv: TFormRecv;

implementation

{$R *.dfm}

procedure TFormRecv.WMCopyData(var Msg: TWMCopyData);
var s : string;
begin
s := String(PChar(Msg.CopyDataStruct.lpData)) ;
ShowMessage(s);
end;

Beim Empfänger kommt nach den ersten Buchstaben nur noch Müll an: 'String T....' Die letzten Buchstaben werden in irgendwelche Sonderzeichen umgewandelt.

Bin für jeden Hinweis dankbar.

Steffen

[mkinzler]

p ist ein Zeiger ins Nirvana

[DeddyH]

Delphi-Quellcode:

with aCopyData do begin
    dwData := 0;
    cbData := (StrLen(p) + 1) * SizeOf(Char); //Größe in Bytes
    lpData := p;
  end;

[runningsoft]

@Detlef

Danke für den Tipp. Genau die Größendefinition war es. Seltsam nur, dass der fehlerhafte Code früher einmal funktioniert haben muss. Ich glaube, das Beispiel stammt von 2003. Weiß aber nicht, mit welcher Delphi-Version erstellt.

Steffen

[DeddyH]

Das war mit Sicherheit eine Ansi-Version (also bis Delphi 2007 einschließlich). In der jetzigen Fassung sollte es aber mit jeder Version passen.

[p80286]

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

Gruß
K-H

[DeddyH]

Wozu PAnsiChar? Jetzt klappt es ja auch, nachdem die übergebene Größe richtig angegeben wurde.

[Luckie]

Zitat:

Zitat von p80286 (Beitrag 1127014)

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

:wall:
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. :roll:

[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:

Zitat von p80286 (Beitrag 1127033)

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.