Kann es sein, daß die Delphi-IDE ein paar Macken beim Unicode hat?

z.B. das Ereignisprotokoll:

zusammenfalten · markieren

Delphi-Quellcode:

var
  S: string;
  A: AnsiString;
begin
  S := 'TELENERG-ŁÓD';
  if Ord(S[10]) <> 321 then // ging keim kopieren/speichern das Unicode kaputt
    S := 'TELENERG-'#$0141'ÓD';
  OutputDebugString(PChar(S)); // müsste gehen, tut es aber nicht ... das Ł geht kaputt
  OutputDebugStringW(PWideChar(S)); // ist ja das Selbe wie PChar (seit D2009)
  OutputDebugStringA(PAnsiChar(UTF8Encode(S)));
  OutputDebugStringA(PAnsiChar(AnsiString(S))); // das geht natürlich nicht, da hierbei auf jeden Fall die Unicodeinfos verloren gehen

  A := 'irgendwasÚ';
  if Ord(A[10]) <> 218 then
    A := 'irgendwas'#$DA;
  OutputDebugStringA(PAnsiChar(A)); // hmmmm, die Ansiversion nimmt scheinbar ANSI und UTF8 an

  R := UTF8Encode('irgendwas ä');
  SetCodePage(R, $FFFF, False);
  R := R + AnsiString(#$DA);
  OutputDebugStringA(PAnsiChar(R)); // sooo, ANSI wird als UTF8 interpretiert und wenn nicht nach Unicode konvertierbar, dann als ANSI

  // aber dennoch blöd, daß Unicode-OutputDebugString nicht funktioniert ... es kann doch nicht sein, daß man alles selber machen muß :wall:
end;

und bei der Dateisuche hab ich auch schon immer Probleme.
- ist eine Datei schon in der IDE geladen, dann funktioniert "Suchen in Dateien", ber ist die nicht geladen, dann kann man alles mit Unicode vergessen
- - Unicodezeichen zu suchen geht nicht
- - und wenn man etwas "ANSI" sucht, in Dateien die Unicode enthalteb, dann geht es praktisch nur, wenn die Datei auch als UTF8 gespeichert ist, wobei in den Suchergebnissen die UTF8-Codes sichtbar sind.

Bei S := 'alle ä suchen'; in einer Datei und diese Datei ist nicht in der IDE geladen:
Wenn ich nach dem "ä" suche, dann wird die Datei nicht gefunden und bei der Suche nach "alle", dann steht im Suchergebnis Test.pas(21): S := 'alle ä suchen'; .



Wisst ihr wie toll das ist, wenn man nach einem Unicodeproblem im Programm sucht, und dann der Debugger einen veräppelt?

Noch komischer schaut es aus wenn man den DebugViewer von MS dran hängt und z.B. Chinesische Zeichen anzeigen will.

Zitat:

Wisst ihr wie toll das ist, wenn man nach einem Unicodeproblem im Programm sucht, und dann der Debugger einen veräppelt?

Vor allem dann wenn man mehr zeit damit verbringt teile des Quelltextes dahin zu konvertieren als eigentlichen Code zu schreiben.
PansiChar(AnsiString( bla. blaa
Wenn man so wie ich als Laie nicht jedes Bit und byte kennt ist das schon arg stressig.

Hab bestimmt mehr speicherlecks nur aufgrund der Konvertierungen als nötig sein sollten

gruss

Da kann die Delphi IDE aber nichts dafür möchte ich mal anmerken... Siehe Doku:
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

Zitat:

OutputDebugStringW converts the specified string based on the current system locale information and passes it to OutputDebugStringA to be displayed. As a result, some Unicode characters may not be displayed correctly.

Und was das Speichern angeht:
Wenn die Datei als UTF8 gespeichert ist, hatte ich damit noch keinerlei Probleme. Wenn man allerdings beim Speichern die Frage, ob die Datei als UTF8 gespeichert werden soll, trotz Warnung mit Nein beantwortet, gehen die Zeichen kaputt. Das war aber auch der einzige Fall, bei dem ich das "Problem" hatte, aber da war ich ja selbst schuld.

// EDIT:

Zitat von EWeiss:

Vor allem dann wenn man mehr zeit damit verbringt teile des Quelltextes dahin zu konvertieren als eigentlichen Code zu schreiben.

Solange es keine Warnungen wie bedenkliche Typumwandlung gibt, kann man die Hinweise zu dem Thema ignorieren, Fehler sollten da nicht auftauchen.
Eine implizite String-Umwandlung mit potenziellem Datenverlust von 'string' zu 'AnsiString' kann z.B. zwar Probleme geben, weil Unicodezeichen herausfallen, aber wenn gar keine drin sind, funktioniert das.

Es sind aber keine schweren Probleme.

Speicherlecks sollten auch durch die Konvertierungen nicht entstehen.

Zitat von jaenicke:

Da kann die Delphi IDE aber nichts dafür möchte ich mal anmerken... Siehe Doku:
http://msdn.microsoft.com/en-us/libr...(v=vs.85).aspx

Zitat:

OutputDebugStringW converts the specified string based on the current system locale information and passes it to OutputDebugStringA to be displayed. As a result, some Unicode characters may not be displayed correctly.

Autsch. Also sind doch nocht Win9x-Reste in Win7 und neuer vorhanden.

Zitat von Bernhard Geyer:

Autsch. Also sind doch nocht Win9x-Reste in Win7 und neuer vorhanden.

Streiche Win9x, setze Win 3.x... nur so als Randbemerkung.

Sherlock

OMG

Vielleicht mal im QC anfragen, ob die es bis XE9 vielleicht schaffen dort mal einen Wrapper neben diese APIs zu legen, der direkt String annimmt, nach UTF8 konvertiert und an die AnsiVersion übergibt.

[edit]
Obwohl es wohl besser ist, wenn wir uns selber eine kleine abstrakte Debug-Klasse anlegen, so mit Klassen-Funktionen ala IsDebuggerPresent, OutputDebugString usw., welche sich dann intern für die jeweiligen OS anpasst. (jetzt wo es nicht nur Windows gibt)

Zitat von himitsu:

OMG

Vielleicht mal im QC anfragen, ob die es bis XE9 vielleicht schaffen dort mal einen Wrapper neben diese APIs zu legen, der direkt String annimmt, nach UTF8 konvertiert und an die AnsiVersion übergibt.

[edit]
Obwohl es wohl besser ist, wenn wir uns selber eine kleine abstrakte Debug-Klasse anlegen, so mit Klassen-Funktionen ala IsDebuggerPresent, OutputDebugString usw., welche sich dann intern für die jeweiligen OS anpasst. (jetzt wo es nicht nur Windows gibt)

Also wir verwenden schon seit 10 Jahre eine eigens Implementierte Methode namens TRACE.
Dahinter verbirgt sich (ein mit "$IFOPT ..." verseuchter Code) der dann letztendlich OutputDebugstring aufruft.

Ich dennke hier braucht man nicht Emba wenn man sowas vermisst.

also zumindest im Sourcecode kann ich fast alle Zeichen unter XE verwenden.
Scheint aber abhängig zu sein von wo raus das Zeichen aus der Zwischenablage kommt. Aus word kann ich die Zeichen alle per strg-c/strg-v in Delphi einfügen.
Haut mal nen LeftRight-Override rein