Memo speichern?

[schniede]

Hallo!

Ich möchte den Inhalt eines Memos speichern und nach programstart wieder laden.

Hab nicht die richtige Idee,wie womit am besten.Im memo sollen Namen stehen ,jeder in einer neuen Zeile, unbestimmt wieviele Zeilen da diese sich aus bestimmten Bedingungen einer Tabelle ergeben.
(genau gesagt eine Tabelle von Bestellungen die zusammengefast ist und jeder der irgendwas bestellt hat soll in einem memo oder was weiß ich angezeigt werden).

Nehme das Memo nur weil viele Namen auf einen Blick zu sehen sind, wenn es was besseres oder sinnvolleres ,gibt bin für jeden tip offen.

Was ist eigentlich die max Zeilenzahl eines memos?

hm ,ziemlich dumme Fragen wenn ich es mir so durchlese aber habe noch nie mit nem Memo was gemacht und bin erstmal recht hilflos.

Danke schon mal für eure Antworten!!


P.S. Also mein Gedanke ist - programmende - zeilen aus memo in ini.datei und start das ganze wieder laden.

[Luckie]

Maximale Anzahl am Zeichen unter Win 9x 32 KB unter Win NT ff. unbegrenzt. Steht TextLength auf 0 ist es aber auf 64 KB begrenzt.

Zum Speichern würde sich eine Ini-Datei anbieten. Zum Darstellen, wenn es etwas feiner aussehen soll, ein Listview oder Stringgrid. Ein Memo ginge natürlich auch.

[S - tefano]

Hi,

jeder fängt mal mit irgendetwas an
Beim Memo solltest du dir mal die Methoden LoadFromFile und SaveToFile angucken, die übernehmen für dich das Öffnen und Speichern. Einfach Dateinamen übergeben, und fertig

Bis dann,

S - tefano

[edit]Wo ich Luckies Post gerade sehe, hoffe ich mal dass ich nichts falsch verstanden hab...[/edit]

[Die Muhkuh]

Hier ein beispiel:

Delphi-Quellcode:

procedure TForm1.Form1Close(Sender: TObject);
begin
  memo1.lines.savetofile('d:\test.txt');
end;
//Dieser code bewirkt das nach dem schließen gespeichert wird.

procedure TForm1.Form1Show(Sender: TObject);
begin
  memo1.lines.loadfromfile('d:\test.txt');
end;
//Dieser Code bewirkt das nach dem aufrufen der Form der Text geladen wird

So der code ist ungetestet sollte aber funktionieren
Ist nur mal so die grundlage.
Ich gib dir nachher noch ein beispiel wie man's mit Ini's macht

[Die Muhkuh]

so hier ein Beispiel für die Ini:

Delphi-Quellcode:

uses
  Inifiles;

end
var
  ini : TInifile;


procedure //Wieder ein OnClose-Event der Form!
begin
  ini := TInifile.create ('d:\Test.ini');
    try
      ini.Writestring('Nachricht','Text',Memo1.lines.text);
    finally
      ini.free;
    end;
end;

procedure //Wieder ein OnShow-Event der Form!
begin
  ini := TIniFile.create ('d:\Test.ini');
    try
      memo1.lines.text := ini.Readstring('Nachricht','Text','');
    finally
      ini.free;
    end;
end;

Man kann auch beim OnShow-Event das try und das Finally weglassen!

[schniede]

Hallo !

Ich danke euch für die zahlreichen Antworten und guten Ideen werde mal an die Umsetzung gehn
und schauen was dabei herraus kommt.

Jedenfalls ist mir jetzt alles ein bischen klarer, Danke !

Und wenns mal hakt dann weiß ich ja wo es immer eine Lösung gibt.

mfg schniede

[Christian Seehase]

Moin Spider,

Du meinst wahrscheinlich das OnCreate und das OnDestroy Event, zumal OnClose bei Application.Terminate ausgeführt wird.

Zitat von Spider:

Man kann auch beim OnShow-Event das try und das Finally weglassen!

Wieso?

[Die Muhkuh]

Zitat:

Zitat:

Spider hat folgendes geschrieben:
Man kann auch beim OnShow-Event das try und das Finally weglassen!

Wieso?

Deshalb

Nene, aber hier muss er ja nichts versuchen! Try = Versuche

[Christian Seehase]

Moin Spider,

es ist zwar richtig, dass "versucht" werden soll, den Code zwischen try/finally auszuführen, und im Fehlerfalle auf jeden Fall das was im finally Block steht ausgeführt werden soll, und es ist auch unwahrscheinlich, dass beim ReadString aus einer INI so ein Abbruch auftritt, abers:

Wie leicht kann man, ohne drüber nachzudenken, zwischen Create und Free noch etwas einfügen, das einen Fehler verursachen kann, ohne das man dann auch den try/finally Block nachträgt.
Es ist einfach sauberer grundsätzlich immer die Freigabe von Resourcen sicherzustellen, soweit man das absichern kann, zumal man dann auch nicht jedesmal überlegen muss, ob die Anweisungen zwischen try/finally "gefährlich" sind oder nicht. TRegistry.ReadString kann, im Gegensatz zu TIniFile.ReadString, eine Exception verursachen.

BTW:
Was mir gerade noch auffällt:
Wenn die Verwendung einer Variablen innerhalb einer Prozedur/Funktion/Methode abgeschlossen ist, wie in Deinem Beispiel "ini", sollte man die auch lokal deklarieren.