string mit postmessage übermitteln?

[richard_boderich]

hallo,

ich versuche einen string über eine postmessage von eienem thread an mein form zu senden. mit
einem integer geht das auch wunderbar. ich wuerde gerne wissen ob das auch mit einem string machbar ist?

hab mir schon die msdn angeschaut , da aber nix zu datentypen gefunden :(

Richard

[Gollum]

Hallo,

Du musst den String in einen LongInt umwandeln, dann sollte es funktionieren:

Delphi-Quellcode:

  PostMessage([empfaenger], [command], [wParam], LongInt(PChar(MeinString)));

[richard_boderich]

ok danke geht ;)

[Jens Schumann]

Hallo,
Achtung, Achtung. In 2002 hat mich Hagen eines besseren belehrt.
Entwickler Forum

[Vjay]

Hagens Version ist, wie es gemacht wird.

Man könnte, ausgehend vom Fall, daß Nachrichten nicht ankommen werden, die pointer noch in eine TList eintragen lassen.
Diese Liste müßte je nach Programmart ab und wann überprüft werden.
Wie das genau gelöst wird hängt jetzt vom Programm ab, ob z.B. der Thread immer laufen soll oder nicht.
Wenn er ständig läuft müßte die Liste per CriticalSection gesichert werden, welches das übergeben des Pointers eh überflüßig machen würde.
Muß denn unbedingt postMessage statt sendMessage verwendet werden? Bedenke es gibt auch ein SendMessageTimeout, der von einem Thread aus nahezu alle Nachteile von SendMessage aufheben dürfte.

[Robert Marquardt]

Man kann mit PostMessage durchaus einen Pointer/PChar uebermitteln, solange es nur innerhalb des Adressraums des Programms bleibt.
Versucht man die Adresse zu einem anderen Programm zu schicken, so ist sie dort bedeutungslos, da das andere Programm seinen eigenen Adressraum hat.

Der Fehler bei Jens lag daran das die Stringvariable im Threadobjekt enthalten war. Es konnte also prinzipiell vorkommen das der Thread schon beendet war wenn die Message ankam. Der String war dann natuerlich schon dealloziiert und der Pointer zeigte in den Wald.

[p80286]

Da ich vor dem gleiche Problem, kapere ich den Thread einmal.
z.Zt. habe ich folgenden Code (auf das wesentliche gekürzt)

Delphi-Quellcode:

Unit1

  cFILEDELETION   :string= 'Deletion of Files'+#0;
  cGETSOURCEFILES :string= 'get source Files'+#0;
  cGETTARGETFILES :string= 'get target Files'+#0;

Unit2
...
sendmessage(FReceiver,CM_Start2,0,longint(pchar(CGETSOURCEFILES)));
....

UnitMain

procedure TForm1.CMStart2(var msg:TMessage);
var
  mm : pchar;
begin
  mm:=pchar(msg.LParamLo);
  self.StatusBar1.Panels[3].Text:=mm; {---- hier macht es puff mit einer Zugriffsverletzung}
end;

Ich könnte in msg.LParamLo natürlich auch den Index für ein Array of TextMessages übergeben, aber soviel Aufwand für z.Zt 6 Meldungen?

Was ist da nicht in Ordnung?
(sowohl postmessage als auch sendmessage funktionieren nicht!)

Gruß
K-H

[nahpets]

Hilft das weiter? http://www.delphitricks.com/source-c...ndmessage.html

Ansonsten würd' ich das probieren:

Delphi-Quellcode:

self.StatusBar1.Panels[3].Text := StrPas(mm);

[p80286]

Leider nicht,
das Strickmuster ist das gleiche wobei txt noch eine lokale variable ist, daß sollte tödlich sein.
und StrPas hat auch keine Besserung gebracht. Es kommt irgendein Adresskrüppel in

Delphi-Quellcode:

CMStart2

an.

Gruß
K-H

Edith:
:wall: wenn man genau hinsieht erkennt man auch den Unterschied zwischen ,

Delphi-Quellcode:

msg.LParam

und

Delphi-Quellcode:

msg.LParamLo

!!?*/!#***Codevervollständigung!
Ja ich weiß, der Fehler sitzt immer vor der Tastatur.

Gruß
K-H

[nahpets]

PChar ist doch ein 0-terminierter String. Du übergibst aber bereist eine Constante, die mit #0 endet. Ist das eventuell doppeltgemoppelt?

Also eher so?

Delphi-Quellcode:

cGETSOURCEFILES :string = 'get source Files';
...
sendmessage(FReceiver,CM_Start2,0,longint(pchar(CGETSOURCEFILES)));

oder so?

Delphi-Quellcode:

cGETSOURCEFILES :string = 'get source Files' + #0;
...
sendmessage(FReceiver,CM_Start2,0,longint(CGETSOURCEFILES));

[himitsu]

Geht das an ein anderes Programm?
Wenn ja, dann nicht PChar, sondern PAnsiChar oder PWideChar verwendent.

LongInt() ... in Blick richtung 64 Bit, solltest du hier besser auch die richtigen Typen verwenden.
Für Messages gibt es die Typen LPARAM, WPARAM und LRESULT.

[p80286]

@nahpets
das

Delphi-Quellcode:

+#0

ist nur um sicher zu gehen, das auch wirklich eine Null da steht, ich traue

Delphi-Quellcode:

PChar

da nicht so recht.

@himitsu
Nö kein anderes Programm, aber der Hinweis mit dem Typ: Danke!
Aber mal zurück gefragt, ist PChar nicht der richtige Typ wenn ich nicht weiß ob der String mit 8 oder 16 Bit Chars aufgebaut wird?

Gruß
K-H

[nahpets]

Wenn Du an 'nen String 'ne #0 dranhängst, dann hast Du sie doch schon. Wenn Du dann PChar nicht traust, dass es einen String in einen null-terminierte Zeichenfolge umwandelt, kannst Du doch PChar weglassen ;-)

Habe mal in meinen Quelltexten gesucht, dort sieht das immer (sinngemäß) so aus:

Delphi-Quellcode:

sendmessage(FReceiver,CM_Start2,0,DWord(PAnsiChar(CGETSOURCEFILES)));

Konstanten werden ohne + #0 deklariert.

Und das Ganze funktioniert schon seit Jahren problemlos.

Bitte mal LongInt durch DWord ersetzen, wir brauchen hier keinen Typen, der auch negative Werte zulässt. Und bitte statt PChar mal PAnsiChar nehmen.

Habe halt nur Delphi 7, ob's bei anderen Versionen anders sein muss, weiß ich nicht.

[p80286]

OK die Null spar ich mir, aber das PAnsiChar?
falls ich dann doch einmal einen Unicodefähigen Compiler nutzen sollte, dann liegen doch wohl auch die Constanten als 16Bit Chars vor, und da sollte PAnsiChar doch eher für eine "Verkürzung sorgen?

Gruß
K-H

[himitsu]

Ratet mal, wie intern ein LongString (String, AnsiString, UnicodeString) und auch WideString aufgebaut sind .... Verwaltungsdaten+DemText+#0#0 :stupid:

[nahpets]

Zitat:

Zitat von himitsu (Beitrag 1367547)

Ratet mal, wie intern ein LongString (String, AnsiString, UnicodeString) und auch WideString aufgebaut sind .... Verwaltungsdaten+DemText+#0#0 :stupid:

Langsam hab' ich den Eindruck, ich werd' (oder bin) doch zu alt, um da noch mitzukommen ;-)

Heißt das dann, dass hierbei

Delphi-Quellcode:

cGETSOURCEFILES :string= 'get source Files'+#0;

wir eigentlich ein

Delphi-Quellcode:

'get source Files'#0#0#0

haben und mit PChar dann noch ein #0 dazuhängen und damit dann ein

Delphi-Quellcode:

'get source Files'#0#0#0#0

dabei rauskommt?
Oder kapiert der Kompiler das und macht es von alleine "richtig"?

Und wenn wir schon PChar-Konstanten haben möchten, dann können wir die doch eigentlich auch als PChar deklarieren:

Delphi-Quellcode:

  cFILEDELETION : PChar = 'Deletion of Files';
  cGETSOURCEFILES : PChar = 'get source Files';
  cGETTARGETFILES : PChar = 'get target Files';

Mein olles Delphi 7 frisst das jedenfalls. Oder denke ich jetzt hier um zuviele, altbackenen, Ecken?

[p80286]

Ich meine mich zu erinnern, daß Strings (abgesehen von den Shortstrings) eigentlich aufgemotze PChars sein sollen, aber da ich diesen #0Trailer nach Möglichkeit ignoriere - wofür gibt es die Länge?- gerät das immer wieder in Vergessenheit.

Warum sollte ich in einem Delphi-Programm Konstanten denn als PChar deklarieren?
Aber im Prinzip hast Du recht, da eh nur die Adresse weiter gereicht wird, kann man's auch gleich richtig machen.

Gruß
K-H

[himitsu]

Nein, es sind keine aufgekotzten PChars.
Es sind aufgemotzte dynamische Char-Arrays.

Delphi-Quellcode:

array of char

Delphi verwendet die Längenangabe, aber als Kompatibilität zeigt der interne Pointer nicht auf den Anfang der Steuerdaten, sondern dahinter, und hinter dem letzten Zeichen werden im Speicher noch zwei #0 abgelegt.
So kann der String-Pointer direkt als PChar verwendet werden (zum Lesen).

Der ShortString (der String aus Delphi 1 und davor) ist ein Record, mit einem LängenByte und drauf folgenden Chars.
Char 1 war auf BytePosition 1 und das Längenbyte auf BytePosition 0 ... darum sind Strings auch mit 1 indexiert, obwohl dort das erste Char auf BytePosition 0 liegt
und die Steuerdaten (Länge, Refernzzählung und seit 2009 auch CharSize und CodePage) davor liegen.

[himitsu]

Zitat:

Zitat von p80286 (Beitrag 1367545)

OK die Null spar ich mir, aber das PAnsiChar?
falls ich dann doch einmal einen Unicodefähigen Compiler nutzen sollte, dann liegen doch wohl auch die Constanten als 16Bit Chars vor, und da sollte PAnsiChar doch eher für eine "Verkürzung sorgen?

Untypisierte Konstanten werden an der Verwendungsstelle eingefügt und eventuell angepasst.

Delphi-Quellcode:

const xxx = 'abc';  // untypisiert 
const yyy: string = 'abc';  // typisiert 

PChar(xxx)  // compilerabhängig
PAnsiChar(xxx)  // immer ein Ansistring
PWideChar(xxx)  // immer ein Unicodestring

PChar(yyy)  // immer richtig
PAnsiChar(yyy)  // kann funktionieren (vor 2009), aber muß es nicht
PWideChar(yyy)  // kann funktionieren (ab 2009), aber muß es nicht

[Glados]

Zitat:

Zitat von Jens Schumann (Beitrag 411695)

Hallo,
Achtung, Achtung. In 2002 hat mich Hagen eines besseren belehrt.
Entwickler Forum

Da das Forum nicht erreichbar ist: ist

Delphi-Quellcode:

PostMessage([empfaenger], [command], [wParam], LongInt(PChar(MeinString)));

noch immer verwendbar?
Was genau hat negaH denn da besser gemacht und warum sollte man das oben nicht verwenden?