Hello again,

In verschiedenen Programmen oder Ideen von mir, werden oft einige Datenmengen erfasst, sei es nun Koordinaten, abgeschlossene Abläufe, ein Rechenergebnis oder ein Spielfigurenfortschritt.

Bei kleinen Mengen kann man ja alle Werte in ein Memo einlesen und dieses dann als Save1.txt oder bei besonderer Kreativität und Möchtegernschutz als Save1.Programmaehnlichklingendeendung, welche sich jedoch mit jedem Editor öffnen lässt, speichern.

Gibt es einen Weg verschiedene Attribute (was anderes sind doch Lines, Captions und Texts nicht, oder) der TKomponenten auf elegantere und vor allem zugrifsssichere Art und Weise zu speichern? Ich meine, das Problem setzt erst zu wenn dann noch ein Image mit ins Spiel kommt. Und um die hunderte Zeilen nun zu 'verschlüsseln' bin ich zu skeptisch.
Jmnd sagte mir mal ich solle alles in eine DLL quetschen, aber das kann doch unmöglich der richtige Weg sein, oder?

Danke für die Antworten und das Ernst nehmen meines Problemchens

Naja, normalerweise verwendet man für sowas Streams, genauer gesagt FileStreams, wenn es um die Speicherung von Daten auf der Platte geht. In einen Daten-Stream lassen sich sequentiell Daten schreiben und wieder daraus auslesen. Die Einarbeitung in die Thematik mag am Anfang vielleicht etwas aufwändig erscheinen, aber es zahlt sich aus Im Internet sollten sich einige gelungene Tutorials zur Verwendung von Streams finden lassen, vermutlich auch hier in der DP.

Aber das hat nichts mit Verschlüsselung oder "Sicherheit" zu tun, man kann die Daten aus einem Stream trotzdem lesen und auch verändern, wenn man auch etwas mehr Kenntnisse als die Bedienung eines Text-Editors haben sollte. Wenn du etwas sicher haben willst, dann wirst du wohl verschlüsseln müssen.

Und noch etwas:

Zitat von Lifthrasir:

Gibt es einen Weg verschiedene Attribute (was anderes sind doch Lines, Captions und Texts nicht, oder) der TKomponenten auf elegantere und vor allem zugrifsssichere Art und Weise zu speichern?

Das klingt sehr danach, dass du Daten und Ausgabe nicht voneinader trennst, so wie es sich eigentlich gehört. Die graphischen Komponenten sollten lediglich zur Ausgabe dienen - quasi als Schnittstelle zum Benutzer. Intern solltest du deine Daten jedoch anders verwalten. Wenn du Text hast, dann zum Beispiel in einer String-Variable usw.

mfg

Wie wäre es mit dem XML-Format?

Streamem oder verschlüsseln..
Hmm, scheint auf jedenfall mit einem erweiterdem Arbeitsaufwand verbunden zu sein. Also gut, zuück an's Zeichenbrett

Danke für deine Antwort soweit!

Zitat von patti:

Das klingt sehr danach, dass du Daten und Ausgabe nicht voneinader trennst, so wie es sich eigentlich gehört. Die graphischen Komponenten sollten lediglich zur Ausgabe dienen - quasi als Schnittstelle zum Benutzer. Intern solltest du deine Daten jedoch anders verwalten. Wenn du Text hast, dann zum Beispiel in einer String-Variable usw.

mfg

Um ehrlich zu sein Rechne ich weniger in globalen Variablen (das meinst du doch, oder?), als direkt in graphischen Komponenten, meist einfach um beim Programmtest mögliche Fehler zu erkennen. Bestimmt mache ich berühmte Anfänger-Fehler oder Dinge die man einfach nicht macht. Bitte nicht böse sein, ich bin da einfach unwissend.
Aber ist es für moderne Systeme nicht egal wenn das Programm durch eine unschöne Architektur oder einfach grobe Fehler schwerer wird?

Zitat von Luckie:

Wie wäre es mit dem XML-Format?

muss ich mich mal für belesen, Danke für den Hint

Zitat von Luckie:

Wie wäre es mit dem XML-Format?

Wobei man dann halt wieder einfachen Text hat, den man einfach im Text-Editor öffnen kann (zugegeben, das wär jetzt kein KO-Kriterium).
XML ist sicher ne feine Sache, aber es kommt auch auf den Anwendungsfall an. XML erzeugt bei kleinen Daten m.M.n. zu großen Overhead und ist manchmal einfach nicht nötig. Zudem ist man halt immer auf einen Parser angewiesen, damit man die Daten wieder lesen kann.

Zitat von Lifthrasir:

Um ehrlich zu sein Rechne ich weniger in globalen Variablen (das meinst du doch, oder?), als direkt in graphischen Komponenten, meist einfach um beim Programmtest mögliche Fehler zu erkennen. Bestimmt mache ich berühmte Anfänger-Fehler oder Dinge die man einfach nicht macht. Bitte nicht böse sein, ich bin da einfach unwissend.
Aber ist es für moderne Systeme nicht egal wenn das Programm durch eine unschöne Architektur oder einfach grobe Fehler schwerer wird?

Niemand ist dir böse, aber es gehört einfach zum guten Programmierstil, dass man die Ausgabe klar von den Daten trennt Gerade am Anfang neigt man dazu, alles durcheinander zu bringen, dadurch schleichen sich aber leichter Fehler ein und alles wird unnötig kompliziert. Es erscheint im ersten Moment einfacher und schneller, Daten und Ausgabe zu verknüpfen, aber gerade bei komplexeren Programmen wird es dann bald undurchschaubar. Nur so als Tipp am Rande

Zitat von Luckie:

Wie wäre es mit dem XML-Format?

Ja, das ist sehr praktisch - vor allem wenn man das Laden und Speichern nicht selber erledigen muss, sondern die Daten in TPersistent-Unterklassen hält. Die kann man mit OmniXml z.B. direkt lesen und schreiben, sozusagen ein Objektrelationaler Mapper für Einsteiger.

JSON ist ähnlich geeignet. Mit SuperObject ist auch hier das Laden und Speichern schnell umgesetzt, und es hat deutlich weniger spitze Klammern als XML.

Wer Erinnerungen an die gute alte Windows 3.0 Ära wecken will, kann auch INI Dateien verwenden.

Zitat von mjustin:

Wer Erinnerungen an die gute alte Windows 3.0 Ära wecken will, kann auch INI Dateien verwenden.

Das klingt recht abwertend... Desweiteren nenne mir mal die gängigen Möglichkeiten, (Konfigurations-)Daten unter Win98/ME komfortabel zu speichern / auszulesen, wenn Du Ini-Dateien und die Registry unberücksichtigt lässt.

Für Kleinigkeiten, wie bspw. Programmeinstellungen, sind Ini-Dateien noch immer sehr nützlich - und einfach!

Zitat von Lifthrasir:

Bei kleinen Mengen kann man ja alle Werte in ein Memo einlesen und dieses dann als Save1.txt oder bei besonderer Kreativität und Möchtegernschutz als Save1.Programmaehnlichklingendeendung, welche sich jedoch mit jedem Editor öffnen lässt, speichern.

meinst du tatsächlich die Komponente TMemo ... dann definitiv never ever!

Vernünftig wird es die Daten in eine Klasse zu packen und dieser Klasse das Speichern und Laden beizubringen.

Danke für die vielen Antworten..
Ich werde mich mal mit kleinen Demos durch die Lösungsvorschläge hangeln.

Hallo

Vielleicht hilft Euch der Delphimanager weiter.

Gruss

Holzfreak