String via Sendmessage unvollständig

[Ajintaro]

Hallo DP,

ich nutze auf meiner Hauptanwendung idHttp und sende POST requests an einen Server. Obwohl ich idAntiFreeze benutze, friert die Anwendung regelmäßig ein, ganz besonders wenn die Internetverbindung etwas langsamer ist. Dadurch sind die anderen Funktionen der Anwendung kaum nutzbar und deshalb möchte ich den POST request eine andere Applikation erledigen lassen.

Dazu habe ich eine neue Formularanwendung erstellt, die

1. über meine Hauptanwendung bei Bedarf gestartet wird und
2. via Sendmessage mit der Hauptanwendung kommuniziert

Die Hauptanwendung muss lediglich die URL an die Sekundäranwendung übermitteln, damit diese den POST request absetzen kann. Sobald ein Ergebnis vorliegt, meldet die Sekundäranwendung den Status an die Hauptanwendung. Mein Problem ist, dass der String per SendMessage nicht mehr als 6 Zeichen verträgt:

Sender Code:

Delphi-Quellcode:

procedure TForm1.Button1Click(Sender: TObject);
  var DataStruct : CopyDataStruct;
begin
  DataStruct.dwData := 0;
  DataStruct.cbData := length(Edit1.Text)+1;
  DataStruct.lpData := pchar(Edit1.Text);

  SendMessage(FindWindow('TForm1', 'Recipient'),
                          WM_CopyData, Form1.handle, integer(@DataStruct));

end;

Empfänger Code:

Delphi-Quellcode:

    procedure CopyData(var Msg: TWMCopyData); message wm_CopyData;
:
procedure TForm1.CopyData(var Msg: TWmCopyData);
var sMsg: String;
begin
  if IsIconic(Application.Handle) then
    Application.Restore;
  sMsg := PChar(Msg.CopyDataStruct.lpData);
  lbMsg.Caption := sMsg;
end;

Leider sind die Ergebnisse alle unvollständig und es gibt unterschiedliche String-Längen. Hier ein paar Beispiele:
String 1234567890 wird zu 123456
String Edit1 wird zu Edi
String www.test.de wird zu www.te
String Delphipraxis wird zu Delphip

Habt ihr eine Ahnung warum das so ist?

[hathor]

The SendMessage returns an integer value assigned by the code that handled the WM_CopyData message.
http://delphi.about.com/od/windowssh...m_copydata.htm

Ausserdem: PChar: PANSICHAR, PWIDECHAR...???

Info:
http://michael-puff.de/Programmierun...COPYDATA.shtml

[Captnemo]

Probiert mal statt

Code:

  DataStruct.cbData := length(Edit1.Text)+1;

Code:

  DataStruct.cbData := SizeOf(Edit1.Text)+1;

Oder schau mal Hier

[Sir Rufo]

Ich habe schon mal keine Ahnung, warum du das in einer Sekundäranwendung auslagerst.

Delphi-Quellcode:

TIdAntiFreeze

ist Kindergarten. Dort wird nur ein

Delphi-Quellcode:

Application.ProcessMessages

ausgeführt, wenn ein Datenblock übertragen wurde. Darum verschlechtert sich auch das Verhalten bei einer langsamen Leitung.

Lagere den Versand in einen Thread aus und alles wird schön.

[r.koch]

Zwei voneinander unahängige VCL-Anwendungen lassen sich mit den jeweiligen Fremdkomponenten recht schnell zusammenklicken.

Danach schickt man von der einen Nachrichten an die andere, um die Andere fernzusteuern. Und von der Anderen schickt man Nachrichten zwecks Kontrolle zurück an die eine.

Wenn und falls das problemlos klappt, ist man sehr glücklich über seine beiden kommunizierenden VCL-Anwendungen!

Wie man aus den zwei VCL-Anwendungen nun nur noch eine mit Threads macht, sollte abhängig von der verwendeten Delphi-Version nicht ganz so trivial oder simpel sein, wenn die beiden VCL-Anwendungen bisher ihre Ausgaben auf dem Bildschirm darstellten.

Der ferngesteuerten Anwendung ihre Bildschirmausgaben wegzunehmen, um sie in einen Thread auszulagern, dürfte nicht ganz so einfach werden.

Insofern habe ich vollstes Verständnis für Sekundäranwendungen.

Welchen Vorteil hätte eigentlich ein Hauptprogramm mit zusätzlichem Thread, wenn der Thread abschmiert gegenüber zwei Programmen, die miteinander kommunizieren?

[Sir Rufo]

Zitat:

Zitat von r.koch (Beitrag 1317955)

Welchen Vorteil hätte eigentlich ein Hauptprogramm mit zusätzlichem Thread, wenn der Thread abschmiert gegenüber zwei Programmen, die miteinander kommunizieren?

Ähm, wir sprechen hier von einem simplen HTTP-Request der in einem Thread ausgeführt werden sollte. Was soll dir denn da um die Ohren fliegen?

Wenn schon paranoid, dann doch auch bitte konsequent und die Sekundäranwendung auf einem separaten Rechner (im klimageregelten Tresor) laufen lassen. Der Austausch der Daten dann per MSMQ/ActiveMQ (transaktionsbasiert) damit auch ja nichts verloren gehen kann. Und dann noch die Reset-Taste des Rechners mit der Sekundäranwendung an das Netzwerk(*) anschliessen - man kann ja nie sicher sein, dass der sich nicht festfrisst.

Gut, man fragt eigentlich nur ein paar Daten von einem Webserver ab ... also etwas, das jeden Tag von Millionen von Menschen mit einem Rechner und einer Anwendung tausendfach passiert ... aber man kann ja nicht vorsichtig (paranoid) genug sein ... :mrgreen:

(*) Um diesen Reset-Taster per Netzwerk anzusprechen, reicht ein simpler HTTP-Request aus ... ;)

[Sir Rufo]

Wenn der Server nicht erreichbar ist, dann bekommt man eine Exception und gut ist.

Davon schmiert weder die Anwendung noch der Thread ab. Die Exception geht einfach ihren kontrollierten Weg, den man auch noch beeinflussen kann.

[Luckie]

Bitte unterlasst es eure persönlichen Abneigungen hier öffentlich auszutragen.

Davon abgesehen halte ich einen zweiten Prozess für einen HTML Request auch für Overkill und unsinnig. Genau dafür sind Threads da, um Aufgaben im Hintergrund zu erledigen. Ein zweiter Prozess geht natürlich auch, aber da gestaltet sich die Interprozesskommunikation doch schon erheblich schwieriger. Ist der erste Prozess noch da? Kann er meine Nachricht empfangen oder ist er beschäftigt? Wie übermittele ich komplexe Daten? Bei einem Thread liegt alles im gleichen Prozessraum und ist einfach erreichbar. Und der "Auftraggeber" bestimmt wie was läuft.

[Daniel]

Ich habe hier die Antworten, die mich sprachlos machten, entfernt.
Das Grundproblem ist ja, dass die Anwendung einfriert, wenn die Daten zu langsam kommen. Die fachlich gängige Lösung sind hier nunmal Threads.

Zitat:

Aber er überfordert sehr oft meinen Pascal-Horizont mit seinen aktuellen XE/Seatle Vereinfachungen.

Das ist in Ordnung, wir haben diese Plattform, um voneinander und miteinander etwas lernen zu können. Wenn man eine Lösung nicht versteht, sollte man nachfragen und nicht schimpfen.

[Neutral General]

Ernsthaft? So viele Antworten und noch keiner konnte eine richtige und klare Antwort auf das hier zustande bringen? :roll:

Das Problem ist, dass in XE6 (genauer: Ab Delphi 2009) die Chars in deinen Strings 2 Byte groß sind und DataStruct.cbData die Anzahl der zu sendenden Bytes möchte und nicht die Anzahl der Zeichen.
Von daher:

Delphi-Quellcode:

DataStruct.cbData := Length(Edit1.Text)*SizeOf(Char);

Darum werden deine Strings auch ziemlich genau ab der Hälfte abgeschnitten.

Zitat:

Zitat von Captnemo (Beitrag 1317937)

Probiert mal statt

Code:

  DataStruct.cbData := length(Edit1.Text)+1;

Code:

  DataStruct.cbData := SizeOf(Edit1.Text)+1;

SizeOf(Edit1.Text) gibt immer SizeOf(String) = SizeOf(Pointer) zurück. Also 4 in 32-Bit und 8 in 64-Bit Anwendungen.