+- LabVIEWForum.de (https://www.labviewforum.de)
+-- Forum: LabVIEW (/Forum-LabVIEW)
+--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein)
+--- Thema: bedienelemente (/Thread-bedienelemente--5766)
bedienelemente - marscru - 19.05.2009 13:05
guten tag liebe gemeinde,
ich habe folgendes problem:
ich erzeuge mir einen array welcher zur steuerung eines frontpanelelements dient. der inhalt dieses arrays stellt die auswahlmöglichkeiten einen kombinationsfeldes dar. da ich diesen array editierbar gestaltet habe ändern sich die elemente. nun habe ich aber das problem da die änderungen auch nach einem neustart von LabVIEW nochvorhanden sein sollen und nicht wieder auf den programmieren default zurück gehen sollen.
ich finde keinen passenden eigenschaftsknoten. um geänderte werte auch nach einem LabVIEW neustart zu erhalten muss ich händig -> datenoperation-> aktuellen wert als standard.
ich bräuchte also eine anordnung die das automatisch löst^^
danke für all den gehirnschmalz der dafür verwendet wird.
lg
bedienelemente - jewi - 19.05.2009 13:54
Du kannst die Werte die du speichern willst in eine Textdatei schreiben. Das ist keine große sache. Dafür gibt es auch einige Beispiele.
Nach jedem Programmstart liest du diese Initialisierungsdatei ein und hast alle alten Werte wieder.
bedienelemente - marscru - 19.05.2009 14:03
ja sry, hab ich vergessen zu schreiben. genau das ist keine option^^. liegt an der späteren verwendung des programms.
sonst wäre es ja zu einfach.
bedienelemente - jewi - 19.05.2009 14:23
Das Programm behält seine alten Werte. Aber wenn du LabVIEW schließt und wieder öffnest sind die Werte natürlich weg. Da würde mir als Lösung aber nur eine externe "Datenbank" einfallen. Und wenn die Datenbank nur eine Textdatei ist.
Warum ist diese Lösung für dich nicht machbar? Vielleicht fällt mir ja doch noch was anderes ein...
LV8.5
bedienelemente - RoLe - 19.05.2009 15:07
' schrieb:ja sry, hab ich vergessen zu schreiben. genau das ist keine option^^. liegt an der späteren verwendung des programms.Entscheidend ist, ob du daraus eine EXE machst.
sonst wäre es ja zu einfach.
Eine EXE kannst du das nicht ändern, mir wäre da auch kein "gutartiges" Programm bekannt, dass sich selber ändert.
Falls deine fertige Lösung in der LV-IDE läuft, könnte man sich was überlegen, aber ... die spätere verwendung des programmes ?
bedienelemente - TSC - 19.05.2009 15:41
' schrieb:Entscheidend ist, ob du daraus eine EXE machst.
Eine EXE kannst du das nicht ändern, mir wäre da auch kein "gutartiges" Programm bekannt, dass sich selber ändert.
Falls deine fertige Lösung in der LV-IDE läuft, könnte man sich was überlegen, aber ... die spätere verwendung des programmes ?
man könnte jetzt dynamisch codeerzeugung auf den tisch brignen. in LabVIEW kein übliches mittel (wenn überhaupt machbar) aber wenn das .NET framework vorhanden ist köntne man sicherlich über eine dll die entsprechende schnittstelle aufbauen. im endefekt würde man dann aber auch nur den quellcode eines c#, vb oder ähnlichen programms abändern, neu compilieren, in ne dll packen und verwenden. sprich man würde die gewünschten infos in eine datei schreiben.
Ich glaube es wäre interessant zu wissen, warum man keine datei auf dem zielsystem anlegen kann.
LG
Torsten
bedienelemente - rasta - 19.05.2009 17:05
Hallo marscu,
die Shared variables haben so die Eigenart, das die Werte erhalten werden auch wenn LV nicht läuft.
Mögliche Lösung: Im Projekt neue Variable erstellen, hoffen das dein Datentyp damit vereinbar ist,
wenn nein Dein Datentyp Flatten to String und als String puffern und anschließendes Unflatten..
Somit existiert jetzt eine Shared Variable die Du in Deinem Programm beschreiben musst und in deiner Initialisierung (vielleicht noch mit FirstCall abfangen) Lesend dein Arrayzustand wieder herstellen kannst.
Im Anhang ein kleines lv85Testprojekt mit dem Bsp von Jewi.
Gruß
Ralf
bedienelemente - jg - 19.05.2009 17:14
Und was macht man, wenn der Rechner neu gestartet wird? Ich kann mir nicht vorstellen, dass die Shared Variables dann noch den Wert vom letzten Stand beibehalten?!
Ich verstehe wirklich nicht, was gegen Speichern in einem FIle sprechen soll, das ist Standard-Vorgehen!
Gruß, Jens