AnsiString in Android App

[Alex_ITA01]

Hallo zusammen,
Ansistring gibt es ja in Android Apps nicht.
Wenn ich dies aber zwingend benötige (da ich mit nicht Unicode Strings -> also 1 Byte für 1 Char) arbeite, brauche ich das natürlich.
Ich habe dies hier gefunden:
http://www.delphifeeds.com/go/f/1111...hiFeeds.com%29

Soll ich das einfach einbinden und dann kann ich meine Variablen als Ansistring deklarieren?
Nachwirkungen oder irgendwelche anderen Probleme habe ich dadurch nicht oder?

Grüße

[himitsu]

Zitat von Alex_ITA01:

Soll ich das einfach einbinden und dann kann ich meine Variablen als Ansistring deklarieren?

Laut Beschreibung würde ich Ja sagen.

Zitat von Alex_ITA01:

Nachwirkungen oder irgendwelche anderen Probleme habe ich dadurch nicht oder?

Nja, es ist von Andy ... Wer würde da mit großen Nebenwirkungen rechnen?


Oder du verwendest einfach ein Byte-Array, wenn du eine Reihe von "1" Bytes benötigst.

[mkinzler]

Zitat:

Nja, es ist von Andy ... Wer würde da mit großen Nebenwirkungen rechnen?

Es ist nicht so, dass der nextgen compiler keine AnsiStrings könnte; die Funktionalität ist nur "versteckt" und Andy macht diese wieder nutzbar. Fehler wären also ihn nicht zurechenbar.

[Alex_ITA01]

Ah ok. Wieso versteckt man das?
Habe es übrigens getestet, geht

[Bernhard Geyer]

Zitat von Alex_ITA01:

Ah ok. Wieso versteckt man das?
Habe es übrigens getestet, geht

Weil es schwieriger ist 10 verschiedene Stringtypen auf neue Plattformen zu Portieren als nur noch eine.

Brauchst du wirklich AnsiString? Oder willst du das nur als Bytebuffer mißbrauchen?

[Alex_ITA01]

Ja ich brauche wirklich ein AnsiString.

Wie kommt man denn darauf diese System.ByteStrings im Hexeditor zu ändern?
Also woher kommt die Ursprungsdatei denn? Im XE7 ist die ja nicht enthalten.
Wie kommt man auf solche Sachen?

[Bernhard Geyer]

Zitat von Alex_ITA01:

Ja ich brauche wirklich ein AnsiString

Wieso? Ich denke das unter Android die meisten Apis Unicode-Enabled sind. Die Java-Apis sowieso

[himitsu]

TEncoding kann den AnsiString von Bytes in Unicode umwandeln und beim Speichern kann man es wieder zu ANSI machen.
TStringList, TFile.ReadXXX, TStringStream, TFileStream+TBinaryReader uvm. können auch Ansi einlesen und dann in Unicode umwandeln.

Und wenn es wirklich ANSI bleiben muß, dann liest man es eben als TBytes ein und wandelt es nicht um.

[Alex_ITA01]

Ich gucke mir das mit den TBytes mal an, vielleicht kann ich ja wirklich darauf umsteigen.

Trotzdem nochmal so gefragt:

Wie kommt man denn darauf diese System.ByteStrings im Hexeditor zu ändern?
Also woher kommt die Ursprungsdatei denn? Im XE7 ist die ja nicht enthalten.
Wie kommt man auf solche Sachen?

Grüße

[jbg]

Zitat von Alex_ITA01:

Also woher kommt die Ursprungsdatei denn?

Die Ursprungsdatei liegt auf meiner Festplatte und sie so aus.

Delphi-Quellcode:

unit System.ByteStrings;

interface

{$IFDEF NEXTGEN}
type
  ShortString = _ShortString;

  AnsiString = _AnsiString;
  AnsiChar = _AnsiChar;
  PAnsiChar = _PAnsiChar;
  PPAnsiChar = _PPAnsiChar;

  UTF8String = _UTF8String;
  PUTF8String = _PUTF8String;

  RawByteString = _RawByteString;
  PRawByteString = _PRawByteString;
{$ENDIF NEXTGEN}

implementation

end.

Diese lässt sich aber so nicht kompilieren, da die Symbole in der System.dcu nicht mit Unterstrich anfangen, sondern mit "@" (der Compiler ändert alle führenden Unterstriche in System.pas zu "@" ab). Der Patch besteht nun darin, die System.dcu Datei etwas zu recht zu biegen, System.ByteStrings zu kompilieren und danach die System.ByteStrings Unit auf "@" zu patchen.
Es ginge natürlich auch noch einfacher, in dem man die System.pas ändert und neu kompiliert. Aber dann hat man mit Packages und Unit-Abhängigkeiten so seine Probleme.

Zitat:

Wie kommt man auf solche Sachen?

Durch so falsche Aussagen, wie "der Nextgen-Compiler kann nur UnicodeStrings, die anderen Stringtypen werden nicht auf ARM Prozessoren unterstützt". Ein Stringtyp hat mal überhaupt nichts mit dem Prozessor zu tun. Zudem wurden die anderen Stringtypen nur versteckt, ihre Funktionalität ist aber voll gewährleistet (alle Compiler-Magic Funktionen sind vorhanden) und wurde weder von XE3, XE4, XE5, XE6 noch XE7 entfernt.