AnsiString zu String zuweisen ohne Konvertierung?

[Bbommel]

Hallo Rolf,

ich habe mal ein kleines Testprogramm gebastelt und bekomme die Zeichen hier mit Hilfe eines RawByteString und mit TmemIniFile korrekt, wenn ich deine Anforderung richtig verstanden habe:

Delphi-Quellcode:

program readansiini;

{$APPTYPE CONSOLE}

{$R *.res}

uses
  System.SysUtils,
  IniFiles;

var
  myIni: TMemIniFile;
  rawStr: RawByteString;
  uniStr: string;
  i: integer;

begin
  try
    { TODO -oUser -cConsole Main : Code hier einfügen }
    myIni:=TMemIniFile.Create('test.ini',TEncoding.ANSI);
    rawStr:=rawByteString(myIni.ReadString('test1','password',''));
    write('Raw: ');
    for I := 1 to Length(rawStr) do
      write(ord(rawStr[i]).ToString+' -- ');
    Writeln(rawStr);
    Write('Unicode: ');
    uniStr:=myIni.ReadString('test1','password','');
    for I := 1 to Length(uniStr) do
      write(ord(unistr[i]).ToString+' -- ');
    writeln(uniStr);
    readln;
    myIni.Free;
  except
    on E: Exception do
      Writeln(E.ClassName, ': ', E.Message);
  end;
end.

In der Datei test.ini steht an der zweiten Stelle das von dir erwähnte Zeichen Hex 96 (also Dec 150). Im rawByateString bleibt es auch korrekt erhalten, im Unicode-String wird es, wie von dir beschrieben, umgewandelt. Die Ausgabe vom Programm ist hier also (wichtig ist die zweite Zahl):

Code:

Raw: 116 -- 150 -- 116 -- 252 -- 116 -- 228 -- t-tütä
Unicode: 116 -- 8211 -- 116 -- 252 -- 116 -- 228 -- t-tütä

Das heißt: damit müsstest du deine bisherigen Daten doch ohne for-Schleife und ähnliches lesen und konvertieren können?

[TiGü]

Verstehe nicht, warum du dir nicht einfach TIniFile rauskopierst und die Aufrufe entsprechend anpasst:
GetPrivateProfileString -> GetPrivateProfileStringA
WritePrivateProfileString -> WritePrivateProfileStringA
MarshaledString -> MarshaledAString

Das ist doch eine Sache von zwei Minuten.
Du programmierst mindestens seit dem Jahre 2006 in Delphi, das ist doch kein Hexenwerk?!?!

[Rolf Frei]

@Bbommel
Danke für deine Bemühungen, aber das habe ich ja schon erwähnt, dass es mit einem TMemIniFile klappen würde. Das habe ich bereits in einem Post erwähnt und auch erklärt, wieso mir das nicht so recht gefällt. Dass da immer das ganze INI File geladen und geschrieben wird ist nicht ideal. Brauche es aber nun dennoch, weil so das Problem vorerst behoben ist.

@TiGü
Natürlich könnte ich das so machen, aber das wäre der absolut letzte Ausweg, wenn nichts anderes gehen würde. Ich kann das Problem mit einem TMemIniFile lösen, nur gefällt mir das eben nicht so gut, weil das das ganze File bearbeitet und nicht nur einen einzelnen Eintrag. Es hat also einen unnötig grossen Overhead.


Das Thema ist also hiermit für mich gelöst und somit abgeschlossen. Danke für all eure Tips und Ratschläge.

[Bbommel]

Zitat von Rolf Frei:

@Bbommel
Danke für deine Bemühungen, aber das habe ich ja schon erwähnt, dass es mit einem TMemIniFile klappen würde. Das habe ich bereits in einem Post erwähnt und auch erklärt, wieso mir das nicht so recht gefällt. Dass da immer das ganze INI File geladen und geschrieben wird ist nicht ideal. Brauche es aber nun dennoch, weil so das Problem vorerst behoben ist.

Ach, Mist, dann hatte ich genau den Post dazu übersehen. Sorry für den Hinweis auf etwas, was du schon wusstest. Aber wenigstens funktioniert es.

[Moombas]

Mal eine komplett andere, vielleicht bekloppte Frage: Warum speicherst du die Ini-Datei nicht einfach im entsprechenden Format (von Delphi)?
Also:
- Original Datei öffnen
- Neue Datei erstellen (leer) und im richtigen Format speichern
- Inhalt der Original-Datei in die neue kopieren und abspeichern
- Original-Datei ersetzen

Dann müsste lesen/schreiben doch problemlos funktionieren!?
Zumindest hat mir das bei Lazarus den A**** gerettet, ohne das ich groß rum programmieren musste.

[TiGü]

Ähm...dir ist schon klar, was genau unter der Motorhaube passiert, wenn man mit dem TIniFile und damit mit den oben erwähnten Windows-Funktionen arbeitet?

Da wird die Datei auch immer komplett geöffnet (CreateFileW, CloseHandle) und zwar für JEDEN einzelnen String, den man sich per TIniFile.ReadString holt.
TMemIniFile ist in der Hinsicht sogar effizienter, weil man viel viel weniger mit dem Dateisystem hantiert.

Ein Blick in die Sourcen vom Wine-Projekt sind an der Stelle ganz erhellend:
https://github.com/ValveSoftware/win...rofile.c#L1088

[Uwe Raabe]

Also hier funktioniert das tadellos mit den Bytes und UnicodeStrings und AnsiStrings. Du darfst nur nicht mit den UnicodeStrings das encode/decode machen. Dafür nimmst du dann die Bytes.

Delphi-Quellcode:

var
  a: AnsiString;
  b: TBytes;
  s: String;
begin
  a := #$33#$95#$34;
  s := a;
  { Der Inhalt von s interessiert hier nicht. Zur Verarbeitung wandeln wir das in Bytes um. }
  b := TEncoding.ANSI.GetBytes(s);
  Assert(b[0] = $33);
  Assert(b[1] = $95);
  Assert(b[2] = $34);
  a := s;
  Assert(a = #$33#$95#$34);
end;

Ich habe jetzt gerade kein Beispiel mit TInifile, aber mit LoadFromFile(<filename>, TEncoding.Ansi) sollte das ebenso funktionieren.

[Rolf Frei]

Zitat von Uwe Raabe:

Also hier funktioniert das tadellos mit den Bytes und UnicodeStrings und AnsiStrings. Du darfst nur nicht mit den UnicodeStrings das encode/decode machen. Dafür nimmst du dann die Bytes.

Delphi-Quellcode:

var
  a: AnsiString;
  b: TBytes;
  s: String;
begin
  a := #$33#$95#$34;
  s := a;
  { Der Inhalt von s interessiert hier nicht. Zur Verarbeitung wandeln wir das in Bytes um. }
  b := TEncoding.ANSI.GetBytes(s);
  Assert(b[0] = $33);
  Assert(b[1] = $95);
  Assert(b[2] = $34);
  a := s;
  Assert(a = #$33#$95#$34);
end;

Ich habe jetzt gerade kein Beispiel mit TInifile, aber mit LoadFromFile(<filename>, TEncoding.Ansi) sollte das ebenso funktionieren.

Beim TIniFile gibt es kein LoadFromFile. Lesen/Schreiben von INI-Files funktioniert nicht auf Filebasis wie eine TStringList. Da wird kein File geladen, da ist das OS dafür zuständig. Da ist auch der Unterschied zum TMemIniFile. Sobald ich im TIniFile eine Wert schreibe ist dieser im File enthalten. Beim TMemIniFile wird das File erst beim Free gespeichert. Das lädt immer das ganze File in den Speicher und schreibt auch wieder das ganze File auf den Disk.

So kann man mit dem TIniFile aus mehreren Progammen gleichzeitig Werte in das Inifile schreiben, ohne dass da was überschieben würde. Beim TMemIniFile steht jeweils nur das drin, was das zuletzt gespeicherte Progamm gespeichert hat. In einer Multiuser Umgebung ist das also sehr ungünstig.

TIniFile schreibt nur die Key/Werte Paare die man will und liest auch nur die, die man will.

Danke nochmals für die Tips.

PS. @TiGü
Dass das OS da das File jeweils öffnet und schliest ist ja logisch. Aber der Unterschied ist halt, dass TIniFile Multiuser/Multiappfähig ist und TMemIniFile nicht.

[himitsu]

Zitat von Rolf Frei:

Beim TIniFile gibt es kein LoadFromFile.

Beim TMemIniFile gibt es die StringList,
aber wie schon erwähnt gibt es die WinAPI für INIs als ANSI und Unicode, und da jeder API-Aufruf ein "eigenständiger" Zugriff ist, lassen sich die APIs mischen.

[TiGü]

Zitat von Rolf Frei:

PS. @TiGü
Dass das OS da das File jeweils öffnet und schliest ist ja logisch. Aber der Unterschied ist halt, dass TIniFile Multiuser/Multiappfähig ist und TMemIniFile nicht.

DAAAAS...ist übrigens eine ganz ganz andere Anforderung, als was du ursprünglich gefragt hattest.

Davon abgesehen:
Was ist das denn? Da schreiben X Benutzer parallel auf einer einzelnen Datei? Wirklich?
Das muss dir doch schon drölfzigmal um die Ohren geflogen sein.

Oder ist es so, wie freimatz vermutet, und jeder Windows-Benutzer hat eine eigene INI-Datei (die hoffentlich in seinem Benutzer spezifischen Ordner liegen)?