string mit postmessage übermitteln?

[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 +#0 ist nur um sicher zu gehen, das auch wirklich eine Null da steht, ich traue 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: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

[nahpets]

Zitat von himitsu:

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

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

Heißt das dann, dass hierbei cGETSOURCEFILES :string= 'get source Files'+#0; wir eigentlich ein 'get source Files'#0#0#0 haben und mit PChar dann noch ein #0 dazuhängen und damit dann ein '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. 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 von 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?

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 von Jens Schumann:

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

Da das Forum nicht erreichbar ist: ist 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?