AnsiString in Android App

[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.

[Alex_ITA01]

und wieder was dazu gelernt, danke

[himitsu]

Und nur weil Emba das geglaubt hat, haben die nun die AnsiStrings versteckt?

Ich hatte fast schon Angst, daß man aufpassen muß, ob es Copy, Pos, Insert, Delete und Co. auch noch gibt, da du ja nur die Stringtypen wiederhergestellt hast.



Ich überlege auch noch, ob ich mich näher mit den neuen NextGen-Integertypen auseinandersetzen sollte und versuch rauszufinden, wie/ob man da noch richtig mit Überläufen rechnen kann.
Find es nicht mehr, aber da scheint es einen neuen Integer-Typen zu geben, der nicht als Zweierkomplement gespeichert wird, sondern wo das höchste Bit nur das Vorzeichen darstellt
und dann auch noch das $ZEROBASEDSTRINGS oder $OLDTYPELAYOUT ... abwärtskompatibler Code wird langsam nicht mehr so einfach, bzw. man muß ständig aufpassen, daß der Code überhaupt noch vorwärtskompatibel ist.

Und weswegen man den Schrott mit dem $LEGACYIFEND erfinden mußte, versteh ich auch nicht.
Wenn man das nicht kaputt gemacht hätte, bzw. wenn die Idioten ihren Code selber richtig geschrieben hätten, dann bräuchte man es nicht, daß man IF mit ENDIF anstatt mit IFEND zumachen kann ,
vorallem da seit 4 Delphi-Versionen das ErrorInsideInsight es immernoch richtig als "falsch" markiert.

[himitsu]

Zitat von jbg:

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.

Die können das auch garnicht so schnell ausbauen, da sie intern an Vielen Stellen immernoch AnsiStrings verwenden, also z.B. bei den alten Dateifunktionen (WriteLn) und wo ich vorgestern wieder mal entnervt drübergestolpert bin, der sLineBreak.
In Windows ist das ein _AnsiString und im NextGen ein _AnsiChar.

Echt geil, da ich per Pointer auf den Text zugreifen und ihn als UnicodeString/WideChar in einen Puffer kopieren wollte.
War fast 'ne ganze Bildschirmseite voll, nur um einen Zeilenumbruch mit paar Leerzeichen zusammenzukopieren. (jetzt auf wenige Zeilen gekürzt, da ich mir den Dreck nun zu Beginn von Delphi in einen UnicodeString casten lasse)


PS: Kann es sein, daß du deine Webseite aufgeräumt hast?



Ach ja, wer unbedingt einen PAnsiChar braucht, kann auch den MarshaledAString aus der System.pas nehmen. ("aktuell" ist das ein PAnsiChar, denn auch Android benutzt intern AnsiStrings)

Ich würde gern mal wissen, wie Emba seine uOSUtils kompiliert ... haben die sich da was von dir abgeguckt?