[gelöst] Memo in Ini-Datei

[willi4willi]

Hallo,

wenn ich den Inhalt eines Memo-Feldes in eine INI-Datei schreiben möchte, funktioniert das zwar, aber beim Einlesen wird nach jedem Wort umgebrochen.
Das geschied nicht, wenn die erste Zeile des Memo leer ist - dann ist alles in Ordnung.

Ist das bei Euch auch so? Oder mache ich etwas falsch?

Hier mein Quelltext:

Code: Alles auswählen

 
procedure TForm1.Button1Click(Sender: TObject);
var F: TIniFile;
begin
  F:=TIniFile.Create('./test.ini');
  Try
    f.WriteString('gruppe','memofeld',Memo1.Lines.DelimitedText);
  finally
    f.Free;
  end;
 
end;
 
procedure TForm1.Button2Click(Sender: TObject);
var F: TIniFile;
    s : String;
begin
  F:=TIniFile.Create('./test.ini');
  Try
    S:=f.ReadString('gruppe','memofeld',Memo1.Lines.DelimitedText);
    Memo1.Lines.DelimitedText:=S;
  finally
    f.Free;
  end;
end;       
 

Viele Grüße

Willi4Willi

[mschnell]

Du könntest den memo-Inhalt umkodierren und z.B. alle Zeichen kleiner gleich $20 (Leerzeichen) und das $-Zeichen durch $ plus zwei Zeichen Hexcode der Zeichen-Nummer ersetzten. (Keine Ahnung, ob Du dann noch Spezialitäten wegen der UTF-Codierung beachten musst. Ich vermute nicht.)

-Michael

[theo]

Aus Ini-Dateien kann man nichts mehrzeiliges auslesen. Deshalb ist mschnell's Tipp wohl richtig.
Vllt. kann man sich überlegen, ob XML geeigneter wäre.

[Soner]

Wieso umweg wenn es direkt geht. Du kannst Memo-Inhalt direkt als Ini-Datei abspeichern. Ini-Datei ist nichts anders als eine Textdatei.
TMemo.Lines.LoadFromFile: Memo Inhalt laden.
TMemo.Lines.SaveToFile: Memo Inhalt Speichern.

Dann wäre noch die Eigenschaften IndexOfName, Values, Names von TStringlist (=TMemo.Lines) zu erwähnen.

[gocher]

Code: Alles auswählen

 
    f.WriteString('gruppe','memofeld',Memo1.Lines.DelimitedText);
 

Also als erstes würde ich schon mal nicht DelimitedText nutzen!

Code: Alles auswählen

  f.WriteString('gruppe','memofeld', Memo1.Lines.Text); 

Und danach würde ich mir an Deiner Stelle überlegen welches Zeichen ich für den CrLf nutzen würde, z.B das ¶ (Paragraphen-Zeichen)!

Code: Alles auswählen

  f.WriteString('gruppe','memofeld', StringReplace(Memo1.Lines.Text, #13#10, '¶', [rfReplaceAll]); 

Und zurück:

Code: Alles auswählen

  Memo1.Lines.Text := StringReplace(f.ReadString('gruppe','memofeld', ''), '¶', #13#10, [rfReplaceAll]); 

[willi4willi]

Hallo!

Vielen Dank für die Tipps.

Also, die Eigenschaft Text zu verwenden und vorher das CRLF zu ersetzen, war eine Super-Idee. Hat auf Anhieb funktioniert.

Das hätte ich allerdings auch erwartet, wenn ich die Eigenschaft DelimitedText oder CommaText verwende, denn beide geben ja auch nur einen String zurück.
Die Zeilen sind in Anführungszeichen und getrennt durch Komma.
Das das nicht funktioniert, finde ich etwas merkwürdig.

Danke an alle!

Willi4Willi

[mschnell]

vorher das CRLF zu ersetzen,

Sehr unschön !

1) in Linux ist der Zeilen-Trenner nicht CR/LF, sondern nur LF
2) in UTF-8 kann die Codierung CR oder LF auch als zweiter Teil eines zweistellingen Codes auftreten
3) Wodurch ersetzen ? Damit das ordentlich arbeitet, brauchst Du eine echte Transparentisierung.

-Michael

[mse]

2) in UTF-8 kann die Codierung CR oder LF auch als zweiter Teil eines zweistellingen Codes auftreten

Das stimmt nicht.

[mschnell]

OK. Ich befürchte bei UTF immer das schlimmste....

-Michael

[wp_xyz]

Ja, etwas überzogen ausgedrückt: Strings mit die schwierigsten Konstrukte der Sprache Pascal geworden...

[willi4willi]

Hallo allerseits!

Es hat mir einfach keine Ruhe gelassen und ich habe mich einmal durch die Units geklickt und nun die Lösung selbst gefunden.

Aufgepasst es ist ganz einfach:

Code: Alles auswählen

 
procedure TForm1.Button1Click(Sender: TObject);
var F: TIniFile;
begin
  F:=TIniFile.Create('./test.ini');
  Try
    Memo1.Lines.StrictDelimiter:=TRUE;   // Das ist schon mal ganz gut!
    f.WriteString('gruppe','memofeld',Memo1.Lines.DelimitedText);
  finally
    f.Free;
  end;
 
end;
 
procedure TForm1.Button2Click(Sender: TObject);
var F: TIniFile;
    s : String;
begin
  F:=TIniFile.Create('./test.ini');
  Try
    Memo1.Lines.StrictDelimiter:=TRUE;  // Und das ist des Rätsels Lösung!!!!!
    Memo1.Lines.DelimitedText:=f.ReadString('gruppe','memofeld',Memo1.Lines.DelimitedText);
  finally
    f.Free;
  end;
end;        
 

Man lernt nie aus, auch wenn man schon viele Jahre mit Pascal zu tun hat.

Viele Grüße!

Willi4Willi

[mschnell]

Ja, etwas überzogen ausgedrückt: Strings mit die schwierigsten Konstrukte der Sprache Pascal geworden...

Da Unicode ja heutzutage für professionelle internationale Anwendungen zwingend notwendig ist, war eine Umstellung der Pascal-IDE von ANSI auf Unicode sicherlich unvermeidlich.

Dabei sind die sich widersprechenden Forderungen nach Universalität, intuitiver Handhabung, Plattform-Unabhängigkeit, gute Performance und Kompatibilität zu älteren Versionen (vorhandener Source-Code sollte nach neu-übersetzen noch genauso funktionieren) zu beachten.

Embarkdero hat das mit den dynamisch typisierten Strings einigermaßen hinbekommen, aber auch da gibt es (wie meine Kollegen berichten) jede Menge Ärger.

Da fpc aber (noch) keinen (durchgängigen) Support für "echte" Unicode-Strings hatte (und hat), Lazarus aber unbedingt Unicode fähig werden und dabei natürlich Plattform-unabhängig bleiben musste, wurde die (meiner Ansicht nach fatale) Entscheidung getroffen, UTF-8 Codierung in dem ansonsten unveränderten ANSIString Typ zu verwenden. (MSE verwendet für diesen - vermutlich unvermeidlichen - Zwischenschritt UTF-16, was auch nicht toll ist, aber (zumindest in westlichen Ländern und bei Vermeidung von Mac-Rechnern) wesentlich weniger Ärger macht).

In absehbarer Zeit wird fpc die volle Delphi-XE - kompatible (und hoffentlich darüber hinaus verbesserte und vom Benutzer sinnvoll parametrierbare) Plattform-unabhängige Implementierung von dynamisch typisierten Strings haben. Dann wird Lazarus vermutlich schnell nachziehen und die Verwendung von Strings für den Programmierer wieder ohne explizite Berücksichtigung von Unicode-Irrsinn verwendbar.

-Michael

[theo]

von Strings für den Programmierer wieder ohne explizite Berücksichtigung von Unicode-Irrsinn verwendbar.

Was mich an dir immer wieder am meisten erstaunt ist, dass du beharrlich und voller Inbrunst seit Jahren Unicode-Themen kommentierst obwohl du nicht nur keine Ahnung davon hast, sondern ganz offensichtlich auch keine Ahnung davon haben willst.

[mschnell]

Genau.

Ein Programmierer sollte nur Ahnung von Unicode haben müssen , wenn er Programme schreibt, bei denen die Details der Codierung eine Rolle spielen (Sortierreihenfolge, Umcodierungen, einlesen von codiertem Text von einem Medium, direkte Verwendung der Betriebssystem API, ... ). Dann kann er sich mit Fug und Recht da beliebig tief reinwühlen.

Wenn es einfach nur um irgendwelchen Programm-internen Text (inklusive GUI) geht, sollte dem Programmierer egal sein, wie der Text codiert ist. Er sollte höchstens eine Fehlermeldung bekommen, wenn das, was er da tut, mit der Codierung, die das System aktuell verwendet, nicht geht.

Das ist bei Delphi XE und bei mse einigermaßen so gegeben, (hat aber immer noch diverse Haken und Ösen).

Solange Lazarus nicht annähernd auf diesem Stand ist kann man es wirklich nicht empfehlen. (Ich bin aber zuversichtlich, dass ich das vor der Rente noch erleben werde.)

-Michael

[Socke]

2) in UTF-8 kann die Codierung CR oder LF auch als zweiter Teil eines zweistellingen Codes auftreten

Jedes Byte einer Multibytesequenz hat in UTF-8 das höchstwertige Bit gesetzt (Dezimalwert > 128). Damit kommt man nie in den Bereich von CR (13) und LF (10).

Ein Programmierer sollte nur Ahnung von Unicode haben müssen , wenn er Programme schreibt, bei denen die Details der Codierung eine Rolle spielen (Sortierreihenfolge, Umcodierungen, einlesen von codiertem Text von einem Medium, direkte Verwendung der Betriebssystem API, ... ). Dann kann er sich mit Fug und Recht da beliebig tief reinwühlen.

Wenn es einfach nur um irgendwelchen Programm-internen Text (inklusive GUI) geht, sollte dem Programmierer egal sein, wie der Text codiert ist. Er sollte höchstens eine Fehlermeldung bekommen, wenn das, was er da tut, mit der Codierung, die das System aktuell verwendet, nicht geht.

Meine Meinung ist da ganz anders. Ein Programmierer sollte wissen, wie sich sein eigenes Programm verhält, wenn es mit unterschiedlichen Codierungen arbeitet. Das fängt schon bei dem Datenaustausch zwischen zwei Programminstanzen an. Der Entwickler sollte sicherstellen, dass eine Datei A von Computer 1 auch auf Computer 2 gelesen und wie gewünscht dargestellt wird -- unabhängig davon, was bei den Computern eingestellt ist. Leider ist "Programm-interner Text" nur so lange intern, wie er nicht das Programm verlässt (zum Beispiel auf die Festplatte geschrieben wird).