Komlexen Cluster in INI-Datei speichern

Habe hier einen Cluster, darin enthalten sind neben Zahlenwerten ein weiterer Cluster mit booleschen Elementen und einer Aufzählungstype.
Dieser Cluster soll in einer INI-Datei abgespeichert und wieder gelesen werden. Das bringe ich auch selbst noch zustande, mit umständlichen Aufdrieseln und wieder Zusammenfügen aller Einzelelemente. Aber ich vermute mal, daß es da eine profimäßigere Löung geben muß. Hat dazu jemand eine Idee?

' schrieb:Habe hier einen Cluster, darin enthalten sind neben Zahlenwerten ein weiterer Cluster mit booleschen Elementen und einer Aufzählungstype.
Dieser Cluster soll in einer INI-Datei abgespeichert und wieder gelesen werden. Das bringe ich auch selbst noch zustande, mit umständlichen Aufdrieseln und wieder Zusammenfügen aller Einzelelemente. Aber ich vermute mal, daß es da eine profimäßigere Löung geben muß. Hat dazu jemand eine Idee?

das geht schon, leider kann ich die Teile, die ich dafür verwende, nicht so ohne weiteres aus einem meiner Projekte rausziehen, zum anderen hab ich leider grad nicht die Zeit ein Beispiel dafür zu basteln. im Prinzip mach ich das so:

   

In dem Beispiel verwende ich eine Globale Variable (User Config) statt einem Cluster. Mit einem Cluster könnte man es aber genauso machen, nur muss man noch (rekursiv?) die Cluster im Cluster auflösen. Dabei könnte man sogar die Cluster im Cluster als Sections in der ini-Datei verwenden, wenn man will. Der Trick dabei ist, die Daten als String zu flatten und in der Form in die INI-Datei zu schreiben. Der Nachteil an geflatteten Daten ist, dass der User entweder hexadezimal lesen können muss oder nichts mehr in der INI-Datei mit einem Text-Editor ändern kann.

Das praktische an der Global ist, dass man nach belieben Controls einfügen kann. Wenn die Write Funktion das nächste mal aufgerufen wird, dann werden alle Elemente in der Global in die Ini-Datei geschrieben - vollautomatisch

BTW: ich kann binär lesen;)und dass der User nichts in der INI-Datei mit dem Text-Editor ändern kann ist mir nur recht

der "Read" Case sieht dann so aus:

   

Grüße
CB

Hi Lucki,

ich glaube nicht, dass es eine andere Möglichkeit gibt, eine Ini-Datei im "herkömmlichen" Sinne - d.h. in Klartext und damit leicht editierbar - zu schreiben, ohne dass du deine Elemente aufdröselst! Das geht z.B. in VB auch nicht (da gibts die "Windows-nativen" Funktionen GetPrivateProfileInt und GetPrivateProfileString), und ähnliche Funktionen verwendet LV im Hintergrund auch.

Alternative zu i2dx Version:
Ich habe solche Einstellungen etc., die der User eh nicht sehen muss/darf, schon in Binary-Files geschrieben und die dann beliebig benannt, z.B. settings.set
Der Vorteil ist: Du kannst als zu schreibenden Typ dein komplettes Cluster anhängen, und wenn du's wieder liest gibts du als Definition des zu lesenden Datentyps wieder z.B. über ne globale Variable dein Cluster an und schreibst dann direkt rein. Dabei musst du dir überhaupt keine Gedanken über den eigentlichen Lese- und Schreibvorgang machen! Ich habe so z.B. auch schon mal Ausschnitte aus Kurven weggeschrieben, die der User aus nem längeren Verlauf extrahiert hat, und habe mit dem Ausschnitt z.B. nen Frei-Text (Kommentar zur Kurve) und ne boolesche Information über den Kurvenstatus (Verlauf i.O.) weggeschrieben. Dazu wurde ne separate Anwendung programmiert, mit der der Benutzter am Arbeitsplatz (also nicht am Prüfrechner in der Qualitätssicherung) diese Auswertung machen konnte bzw. nachträglich auch beliebig bearbeiten konnte. Der Nachteil dabei ist, dass du, wenn du die Schreibroutine erweiterst (neue, zusätzliche Informationen), du mit den alten Dateien erst mal nix mehr anfangen kannst...da müsstest du dann ne separate Leseroutine basteln oder ne Umwandlungsroutine "alt-nach-neu" erstellen...

Gruss
Achim

<div align="left">Danke erst mal für eure Antworten. Ein INI-Date ist ja editierbar, aber ich hätte vielleicht noch sagen sollen, daß mir das nicht wichtig ist und daß es mir überhaupt egal ist, in welchen Dateiformat die Speicherung erfolgt. Also es geht darum, daß die Werte ausgewählter Bedien/Anzeigeelemente in einer Datei gespeichert und beim nächsten Aufruf wieder eingelesen werden.
Ich stehe etwas unter Zeitdruck und habe ein Lösung gefunden, die funktioniert. Aber was da eigentlich geschieht, ist mir nicht vollständig klar.
Der Grundgedanke ist der:
Der Cluster
   
wird in eine Variant-Type konvertiert. Als Anzeige (ohne Typ-Def) sieht das dann so aus:
   
Das sieht zwar schon aus wie eine Textdatei, ist aber keine und läßt sich nicht als solche abspeichern. Also konvertiere ich den Variant-Typ noch in Text. Das Ergebnis diese Operatiion sieht aber ganz anders aus als erwartet, nämlich so:
   
Warum der String so aussieht weiß ich nicht. Aber wenn ich diesen String in der INI-Datei speichere und dann wieder lese, dann funktioniert es.
Bei der Konvertierung Variant zu Text gibt es als zweiten Ausgang die "Typdefinition" Sie braucht aber nicht mit gespeichert zu werden. Ich lese sie bei der Konvertierung zu String einmalig aus, mache ein Konstante daraus und verwende die dann die beim Wiedereinlesen aus der INI-Datei.</div>

Hi Lucki,

hm, da kann ich dir grad auch nicht weiterhelfen...ist mir auch nicht so klar, was da passiert...hab aber auch grad net so viel Zeit zum Nachdenken...-_-

Aber ich hab dir mal screenshots von meiner Variante mit den Binärfiles gemacht, die VIs sind von nem Kunden, deswegen kann ich das nicht online stellen!

Hope this helps...

Gruss
Achim

       

' schrieb:Warum der String so aussieht weiß ich nicht.

1 bzw. 0 bzw. 1E sind die ASCII-Darstellungen der Bytes 0x00, 0x01, 0x1E, die in Zahlen ausgedrückt 0, 1 und 30 heißen.

Aus Mode {1, false, false, false} wird also 1000
Aus MinSpeed 30 wird 1E (MinSpeed ist ein int8)
Aus RunCurrent (ein Int32-Wert) 80 wird P000 - Aus 80 als Int32 wird also 0x00000050; 0x50 ist das ASCII-Zeichen 'P'

Das n, was eigenlich A (10) heißen sollte, ist eigentlich ein "Darstellungsfehler": n gilt innerhalb eines Strings als Zeilenvorschub der als 0x0A definiert ist.

usw.

Die erste Darstellung des Variant-Typs ist die "lesbare" Form, die natürlich als solche nicht abgespeichert wird. Die zweite Darstellung ist die Stringdarstellung eines Binären Streams.

Anzeige

<div align="left">Vielen Dank für die Antowrten, jetzt sehe ich durch. Wenn es darum geht, mit geringstmöglichem Programmieraufwand wichtige Einstellungen beim Beenden das Programms abzuspeichen und beim Start wieder einzulesen, dann erscheint mir Achims Methode die beste: Alle interessierenden Werte in einen großen Cluster rein, und den binär abspeichern/einlesen.
@Ichselbst.
Dank für die "Entschlüsselung". Wenn ich eine Kleinigkeit anmerken darf:
Die Darstellung /n statt /0A hat meines Erachtens seine Richtigkeit: /n ist identisch mit der Zeilenvorschub-Konstanten bei den String-Funktionen und ist ein plattformunabhängiges Zeichen. Unter Windows wird es zu intern zu /0A umgesetzt, aber nicht unbedingt unter MAC oder Linux. Der Zweck dieser Übung ist der problemlose Austausch von Textdateien zwischen unterschiedlichen Plattformen unter LabVIEW. Allerdings ist das mehr Theorie als Praxis, wahrscheinlich ist es doch überall gleich, aber ich weiß das nicht genau.
</div>

[OT]

' schrieb:Die Darstellung /n statt /0A hat meines Erachtens seine Richtigkeit: /n ist identisch mit der Zeilenvorschub-Konstanten bei den String-Funktionen und ist ein plattformunabhängiges Zeichen. Unter Windows wird es zu intern zu /0A umgesetzt, aber nicht unbedingt unter MAC oder Linux. Der Zweck dieser Übung ist der problemlose Austausch von Textdateien zwischen unterschiedlichen Plattformen unter LabVIEW. Allerdings ist das mehr Theorie als Praxis, wahrscheinlich ist es doch überall gleich, aber ich weiß das nicht genau.

Du hast recht.

Es ist so: 0x0A bzw. 0x0D bedeuten gemäß ASCII-Tabelle LF (LineFeed: Zeilenvorschuf) bzw. CR (CarridgeReturn: Wagenrücklauf) (guckst du alte Schreibmaschien bzw. entsprechend alter Drucker). Um den Cursor respektive den nächsten Text an den Beginn der nächsten Zeile zu setzen, musst(est) du zwei Sachen machen: Cursor eine Zeile tiefer = Zeilenvorschub und Cursor an Anfang der Zeile = Wagenrücklauf. Dieses Verfahren hat sich beibehalten, sodass jetzt auch der Computer mit dem entsprechenden Betriebssystem respektive ein bestimmtes Programm LFCR (oder CRLF) macht. Anderen Betriebssystemen (respektive Programmen) genügt ein Zeichen (z.B 0x0A) um beide Funktionen zu machen. - Und da man seine Programme gerne unabhängig haben möchte, heißt n halt ganz einfach: Gehe an den Anfang der nächsten Zeile. Wie das wer auch immer realisiert, ist dem Programm egal.

[/OT]