Formulardaten speichern und wiederherstellen

Das ist nett von dir, vielen Dank.
Aber Luckis VIs sind genau das, was ich gesucht habe. Ein neues Element kann dort sehr einfach hinzugefügt werden und der Code selbst ist daher relativ übersichtlich. Deins schaue ich mir dennoch an.

Ich vermisse eine Art LabVIEW-Kochbuch mit genau solchen Beispielen. ;-)

' schrieb:wie man vom SubVI aus feststellen kann, von wem es aufgerufen wurde.

Kann man ableiten mittels des Elementes "Aufrufkette" aus der Palette "Anwendungssteuerung".

' schrieb:@Lucki: Ich verstehe zwar noch überhaupt nicht, wie deine VIs funktionieren, aber es schaut vielversprechend aus. Ich werde versuchen, sie nachzuvollziehen. Vielen Dank.

Ich habe das gemacht, weil ich Deine Anforderung sinnvoll fand, und weil ich selbst auf der Suche nach so etwas Ähnlichem war und keine Lust habe, für jede Speicherung bestimmter Elementewerte jedesmal das Rad neu erfinden zu müssen.
Es ist aber auf die Schnelle gemacht und noch nicht perfekt. Z.B. habe ich nicht untersucht was passiert, wenn man die Werte einlesen will, obwohl noch gar nichts gespeichert ist oder die ini-File überhaupt noch nicht existiert. Auch ist das Fomat nicht hexadezimal, d.h die Stringzeichen haben alle Werte von 0..255. Die INI-File ist deshalb mit einem Editor schlecht lesbar und schlecht editierbar (das könnte man aber ändern).
Als Vorlage diente mir ein Programm "Loading_SavingControlValues.vi", welches ich hier mal gepostet hatte. Das hat sich allerdings nicht besonders bewährt, weil dort alle Bedienelemente des VIs und nicht nur eine Auswahl gespeichert wurden. Z.B würde auch der letzte Wert "Write" des Read/Write-Knopfes mit gespeichert, und das wäre unerwünscht.
Das INI-Format hat den Vorteil, daß man auch Werte in anderer Auswahl, also z.B nur einen bestimmten Einzelwert, Speichern und lesen kann. Außerdem erfolgt die Speicherung in einem betimmten Abschnitt. Man könnte noch andere Abschnitte einrichten und dort ganz andere Sachen speichern. (Aber vielleicht ginge das alles mit dem HTML-Fomat genau so, da kenne ich mich nur nicht aus)

Ich habe mir das heute näher angesehen und mir gefällt das richtig gut. Nochmals danke. :-)

' schrieb:Auch ist das Fomat nicht hexadezimal, d.h die Stringzeichen haben alle Werte von 0..255. Die INI-File ist deshalb mit einem Editor schlecht lesbar und schlecht editierbar (das könnte man aber ändern).

Ja, das ist noch suboptimal, aber vielleicht findet sich hier noch eine Lösung, damit auch die Ini-Datei manuell editiert werden kann.

Hallo Mechatroniker,

"Schön, dass es einige Analogien zu richtigen Programmiersprachen gibt."

Was soll das denn bitte heißen? Damit machst du dir hier keine Freunde

:pony:Genau, wo doch die ganze Textprogrammiererei Mist ist.

Gruß Markus

' schrieb:Was soll das denn bitte heißen? Damit machst du dir hier keine Freunde

Anzeige

Ohje, was habe ich da nun für eine Diskussion angefangen. *g*

"Richtiges" Programmieren ist für mich die klassische Programmierung, in der z.B. OOP vollständig unterstützt wird und nicht nur so minimal wie (noch) in LabVIEW.
Da ich von der Text-Programmierung komme, fällt mir der Umstieg auf LabVIEW leichter. Daher die Aussage.

Aber lassen wir's bitte dabei, sonst wird das Thema zu unübersichtlich. So eine Diskussion könnten wir eher in ein Off-Topic-Thema auslagern. ;-)

' schrieb:Ja, das ist noch suboptimal, aber vielleicht findet sich hier noch eine Lösung, damit auch die Ini-Datei manuell editiert werden kann.

Die Sache ist übrigens nicht ganz so schlimm, wie ich es vielleicht dargestellt habe. Beim VI Write Key gibt es, wenn man als Typ "String" gewählt hat, einen Eingang "Original String schreiben?" Default ist false. Wenn false, dann werden nicht darstellbare Steuerzeichen automatisch in ""-Codes konvertiert. Man hat dann zwar immer noch jede Menge Hiroglyphen im String, aber zumindes bleibt der String immer schön in einer Zeile. Es gibt keine den Text verhunzenden Steuerzeichen wie NewLine usw. Einen entsprechenden Eingang gibt es auch beim VI Read Key.

' schrieb:Man hat dann zwar immer noch jede Menge Hiroglyphen im String, aber zumindes bleibt der String immer schön in einer Zeile. Es gibt keine den Text verhunzenden Steuerzeichen wie NewLine usw. Einen entsprechenden Eingang gibt es auch beim VI Read Key.

Schön fänd ich es, wenn alles in einen darstellbaren String umgewandelt wird, egal um welchen Typ es sich handelt. Dann könne die Konfiguration auch extern bearbeitet werden.

Theoretisch könnte das auch klappen, da sowohl zum Zeitpunkt des Schreibens als auch des Lesens der erforderliche Typ vorhanden ist (über die VI-Eigenschaften).

' schrieb:Schön fänd ich es, wenn alles in einen darstellbaren String umgewandelt wird, egal um welchen Typ es sich handelt. Dann könne die Konfiguration auch extern bearbeitet werden.

Es gibt vieles, was schön wäre. Aber ich betrachte das jetzt nicht als Aufforderung aktiv zu werden. Im Übrigen könnte man bestimmte Elemente in der gleichen INI, wenn man die dort unbedingt editieren möchte, in einem anderen Abschnitt gesondert, in einem besser angepassten Format, abspeichern.