XE2: Probleme mit Umwandlung von Char zu Byte

[Helmi]

Die Idee das mit einer 2. Schleife zu machen, klingt ganz gut.
Einen normalen String zu schicken ist kein Problem - wird vom Modul sauber erkannt und angezeigt.
Nur eben diese Sonderzeichen machen Probleme.

Die Bezeichner bleiben so wie sie sind und haben auch ihren Sinn. Ich weiss das Text auch bei Delphi verwendet wird.
Aber das hindert nicht daran dass man diese auch selbst verwenden kann/darf. Wenn es Sinn macht dann nutz ich diese.

[jaenicke]

Als ich deine Bytewerte eben noch einmal angeschaut habe, ist mir aufgefallen, dass es noch sehr viel einfacher geht...

Delphi-Quellcode:

procedure TMainForm.LCD_Text_senden(Text: String; Zeilenumbruch: Boolean = false;
  leeren: Boolean = false; Schritt: Boolean = false; Verzoegerung: Word = 100);
var
  AnsiText: AnsiString;
begin
  {...}

  SetLength(AnsiText, Length(Text));
  if not CharToOem(PChar(Text), PAnsiChar(AnsiText)) then
    AnsiText := AnsiString(Text);

  {...}

// EDIT:

Zitat von Helmi:

Ich weiss das Text auch bei Delphi verwendet wird.
Aber das hindert nicht daran dass man diese auch selbst verwenden kann/darf. Wenn es Sinn macht dann nutz ich diese.

Da hast du Recht: Man kann und darf. Man sollte nur nicht.
Aber das ist ja deine Sache. Wenn du das erste Mal damit auf die Nase gefallen bist, siehst du es vielleicht anders.

[Helmi]

Zitat von jaenicke:

Delphi-Quellcode:

SetLength(AnsiText, Length(Text));
  if not CharToOem(PChar(Text), PAnsiChar(AnsiText)) then
    AnsiText := AnsiString(Text);

Das wär zu schön um wahr zu sein - sehr schön kurz und so - nur leider passt es nicht ganz!
Z. B. wird "³" (hochgestellte 3) nicht richtig dargestellt)

Zitat von jaenicke:

Da hast du Recht: Man kann und darf. Man sollte nur nicht.
Aber das ist ja deine Sache. Wenn du das erste Mal damit auf die Nase gefallen bist, siehst du es vielleicht anders.

Also wo man mit solche Bezeichner auf die Schnauze fallen könnte (und ich auch schon bin) war in Verbindung mit "with".

[Luckie]

OK bei text mag es noch gehen. Bei Caption wird es aber schon kritisch, da auch ein Formular diese Eigenschaft hat. Und wenn du jetzt eine lokale Variable Caption nennst, weiß ich nicht,ob Delphi weiß, was gemeint ist. Und auch wenn es Delphi wissen sollte, würde es eher verwirren.

[jaenicke]

Zitat von Helmi:

Das wär zu schön um wahr zu sein - sehr schön kurz und so - nur leider passt es nicht ganz!
Z. B. wird "³" (hochgestellte 3) nicht richtig dargestellt)

Hmm, das ist auch das einzige Zeichen. Alles andere passt in die Codepage 850. Die hochgestellte 3 steht aber in keiner Codepage an der Stelle. Wenn alles andere korrekt dargestellt wird, könntest du dafür eine Ausnahme machen. Oder du bleibst bei der Arraylösung.
Aber wie sieht es mit den diversen anderen Sonderzeichen aus? Vielleicht würden diese mit CharToOem ansonsten alle schon funktionieren.

Zitat von Helmi:

Also wo man mit solche Bezeichner auf die Schnauze fallen könnte (und ich auch schon bin) war in Verbindung mit "with".

Benenne den Parameter Text einfach mal um. Normalerweise würdest du dann Kompilierfehler an den Verwendungsstellen bekommen. Da Text aber eine Eigenschaft des Formulars ist, funktioniert es einfach nur nicht mehr...

Anderes Problem: Refactoring

Delphi-Quellcode:

procedure TForm185.Test(Text: string);
begin
  ShowMessage(Text);
end;

Extrahiere einfach mal die Zeile in der Methode. Was kommt heraus? Richtig, das falsche...

Delphi-Quellcode:

procedure TForm185.Test(Text: string);
begin
  ExtractedMethod;
end;

procedure TForm185.ExtractedMethod;
begin
  ShowMessage(Text);
end;

Der extrahierte Code kompiliert aber leider aufgrund der Benennung...
Und nun bemerke den Fehler bei einem etwas komplexeren Code sofort...

// EDIT:

Zitat von Luckie:

OK bei text mag es noch gehen. Bei Caption wird es aber schon kritisch, da auch ein Formular diese Eigenschaft hat.

Ein Formular hat auch die Eigenschaft Text.

[Helmi]

Zitat von jaenicke:

Hmm, das ist auch das einzige Zeichen. Alles andere passt in die Codepage 850. Die hochgestellte 3 steht aber in keiner Codepage an der Stelle. Wenn alles andere korrekt dargestellt wird, könntest du dafür eine Ausnahme machen. Oder du bleibst bei der Arraylösung.
Aber wie sieht es mit den diversen anderen Sonderzeichen aus? Vielleicht würden diese mit CharToOem ansonsten alle schon funktionieren.

Also alle anderen Zeichen schauen gut aus - bis eben das eine.
Ich hab aber jetzt kein Problem damit das mit der Arraylösung zu machen

Wo schaust du bezüglich der Codepage nach?

[jaenicke]

Zitat von Helmi:

Wo schaust du bezüglich der Codepage nach?

Bei Wikipedia:
http://de.wikipedia.org/wiki/Codepage_850
Das ist "unsere". Die anderen sind rechts auf der Seite verlinkt.

[Helmi]

Danke!

[Bernhard Geyer]

Zitat von jaenicke:

Zitat von Helmi:

Wo schaust du bezüglich der Codepage nach?

Bei Wikipedia:
http://de.wikipedia.org/wiki/Codepage_850
Das ist "unsere". Die anderen sind rechts auf der Seite verlinkt.

Ich glaube nicht das XE2 noch DOS-Programme erstellen kann bzw. LED-Lösungen auf DOS-Pages arbeitet.
Schaut nicht ISO 8859-1 besser aus?

[himitsu]

Hab nicht alles nichst gelesen, aber ...

Das Modul ist und bleibt weiterhin ANSI, also mußt du auch bei ANSI bleiben ... zumindestens bei den Schnittstellen.

ANSI-Funktionen ... siehe Unit AnsiStrings


Es muß auch nicht sein, daß die Zeichen dieses Modul überhaupt mit einer bekannten CodePage im PC übereinstimmen.
Oftmals wurde quasi eine "eigenständige" Kodierung verwendet.

Welches Modul eigentlich? (hab hier auf die Schnelle nirgends was dazu gefungen)
Es sollte dazu ja ein Datenblatt geben, wo bestimmt/vermutlich eine Zeichentabelle aufgeführt ist.