Cluster to file(einstellungen speichern)

hab mal eine Frage....

ich will einstellungen im Programm abspeichern können.......alle Werte der zu sichernden Elemente(Pfade, Strings, Numerische, Zeitstempel) fass ich dabei in ein Cluster zusammen. Dieses Cluster schreib ich in ein Array(der Selector bestimmt die Position(begrenzt auf 10)). Das ganze wandel ich in einen string um (Variant nach string) und speicher des in ein text-file. analog erfolgt das laden.

mach ich das so richtig? kann man das so machen? gehts auch einfacher? hab da immer ein mulmiges gefühl wegen den 100 lokalen variablen....

' schrieb:gehts auch einfacher? hab da immer ein mulmiges gefühl wegen den 100 lokalen variablen....

Ich denke nicht. Aber das ist ja nur die halbe Miete: Du willst ja das Abgespeicherte auch mal wieder einlesen.
Und hier kann ich Dir vielleicht einen kleinen Tip geben:
Für das Einlesen braucht Du den nicht abgespeicherten Typenstring. Da der immer gleich bleibt, muß er auch nicht gespeichert werden. Ich habe es so gemacht: Typenstring lesen, so wie Du es gemacht hast. Dann aus der Anzeige eine Konstante erzeugen und diese für das Wiedereinlesen verwenden. Nachdem man das ein Mal gemacht hat, braucht man den Typenstring in Deinem VI gar nicht mehr auszulesen.

http://www.LabVIEWforum.de/index.php?s=&am...ost&p=17160

http://www.LabVIEWforum.de/index.php?s=&am...ost&p=24629

So wie du's machst geht's natürlich auch...und warum hast du ein mulmiges Gefühl bei den Variablen? Es sieht halt nicht so schön aus...du könntest auch die Referenzen einsammeln (PropertyNode des Frontpanel >> [Controls]...damit dann in ein SubVI und in ner FOR-Schleife alle Werte (Variant) auslesen und wegschreiben)


Gruss
Achim

Danke für den tip.......wenn ich die zusammensetzung des clusters ändere setz ich den aktuellen wert von Typenstring immer einfach als standard(im bearbeitungsmodus).....wenn ich mal genau weiß das keine variablen mehr zum cluster dazu kommen mach ich eine konstante aus dem typenstring....

ich hab das ganze auch mal mit "konfigurationsdatei schreiben" gemacht........ABER(....und keiner weiß warum): komischerweise dauert das einlesen manchmal ein paar milisekunden.....manchmal aber auch mehrere sekunden, und das für einen stinknormalen string. ich frag mich was da so lange dauern soll.....BUG???......genau deswegen bin ich auch zur txt-datei übergegangen

Mit XML geht es suuuper einfach und schnell.

eg

boahhhh.....das is ja wirklich simpelst.....klasse......danke für den tip.....der Vorteil dabei ist auch, man kann das XML auch mal öffnen und man hat nicht irgendwelche hyroglyphen vor sich, die man nicht entschlüsseln kann

@achim

die sache ist die, ich will nicht alle Frontpanel-objekte abspeichern....und bis ich des geschnallt hab welches element des [Controls]-array zu welchen objekt gehört.....hab mich auch noch nicht so sehr damit beschäftigt(asche auf mein haupt...)

ich werde mal die xml-variante ausprobieren.....

' schrieb:mach ich das so richtig? kann man das so machen? gehts auch einfacher? hab da immer ein mulmiges gefühl wegen den 100 lokalen variablen....

Selbst schreibe ich solche Informationen in ein INI file aber ansonsten tue ich es ähnlich.

Und ja, lokale Variablen sollten gemieden werden wo immer es geht, aber dies ist eine legitime Anwendung von lokalen Variablen zusammen mit Initialisierung von Frontpanel Elementen am Anfang eines Userinterface VIs.

Es wird da schlimm wo lokale Variablen gebraucht werden um Drähte zu "sparen" und sowieso wenn das innerhalb von Schleifen unzählige Male geschieht.

Rolf Kalbermatter

' schrieb:Selbst schreibe ich solche Informationen in ein INI file aber ansonsten tue ich es ähnlich.

Ich auch. Kleine Begebenheit, nur so zum Spaß: Neulich ging da bei einem Kunden etwas in die Hose. Es wurden Typenbezeichnungen von Testobjekten als Text gespeichert, und in einer dieser Bezeichnungen haben sie doch tatsächlich eckige Klammern [] verwendet. Da diese Zeichen in ini-Dateien aber für die [Abschnitte] reserviert sind, kam es zu unerwarteten Resultaten...

' schrieb:Ich auch. Kleine Begebenheit, nur so zum Spaß: Neulich ging da bei einem Kunden etwas in die Hose. Es wurden Typenbezeichnungen von Testobjekten als Text gespeichert, und in einer dieser Bezeichnungen haben sie doch tatsächlich eckige Klammern [] verwendet. Da diese Zeichen in ini-Dateien aber für die [Abschnitte] reserviert sind, kam es zu unerwarteten Resultaten...

Welche LabVIEW Version verwendest Du? Benützt Du die Standard INI File VIs?

Das kann mindestens seit 7.0 eigentlich nur passieren wenn Du Benützerinformationen verwendest um Keynames zu generieren. In Keyvalues sollten diese Charakter nicht als Anzeichen eines Sektionsnamen erkannt werden.

Rolf Kalbermatter

' schrieb:Welche LabVIEW Version verwendest Du? Benützt Du die Standard INI File VIs?
Das kann mindestens seit 7.0 eigentlich nur passieren wenn Du Benützerinformationen verwendest um Keynames zu generieren. In Keyvalues sollten diese Charakter nicht als Anzeichen eines Sektionsnamen erkannt werden.
Rolf Kalbermatter

Version 8.2.1 Es war genau so wie Du sagst. Bei der Abspeicherung handelte sich um eine Tabelle, in der ersten Spalte stand eine Typenbezeichnung, die folgenden Spalten waren die Parameter diese Types. Die Typenbezeichnungen in der Tabelle hatte ich als KeyNames innerhalb des Abschnittes [Tabelle] verwendet, der Rest der Zeile in der Tabelle (Stringtyp) waren die Values dieser Keynames. Und bei den Keynames ist es auch passiert, nicht bei den Values.