COM-Port in Registry speichern

Hallo liebe LV-Gemeinde,

ich habe ein VI, das mit drei Generatoren über drei serielle Schnittstellen kommuniziert. Den entsprechenden Port muss ich händisch auswählen, was auch so bleiben soll.

Ich möchte nun zusätzlich, dass ich den letzten verwendeten Port für alle drei Tests beim Anklicken der entsprechenden Registerkarte (Reiter "Test 1", "Test 2", "Test 3") auslese.
Wenn ich bei der letzten Nutzung des Programmes für Test 3 COM4 eingestellt hatte, soll das wieder eingestellt sein. Klicke ich auf "Test 2" dann entsprechend COM3 o. ä. ...
Ich habe das VI auf die entsprechende Initialisierung der Ports reduziert um die Problemstellung zu verdeutlichen.

Muss ich die Werte in die Windows registry schreiben und falls ja, kann mir jemand erklären, wie das funktioniert?
Ich freue mich auf Eure Vorschläge

Liebe Grüße
Kaya

Anzeige

Hallo Kaya,

Zitat:Muss ich die Werte in die Windows registry schreiben und falls ja, kann mir jemand erklären, wie das funktioniert?

Man kann die Registry benutzen, muss es aber nicht. Ich würde sie nur sehr selten noch nutzen...

Stattdessen sollten Programme ihre Config-Daten im Benutzerverzeichnis (unter %userappdata%) ablegen. Dort hast du IMMER Schreibrechte und kannst nach Belieben Dateien anlegen/auslesen.
Also einfach deine Config-Daten in einem INI-File speichern und beim Start deines Programms wieder einlesen…

Zu deinem VI:
- Viel zu viele Sequenzen.
- Und dann noch stacked sequences: noch schlimmer!
-> THINK DATAFLOW! und nutze Drähte, um eine Reihenfolge des Codes zu definieren!
- Viel zu viele Warte-Funktionen!
- Und dann noch parallel zu einer Event-Struktur, deren TimeOut-Eventcase EWIG wartet: das ist reiner Rube-Goldberg!

Also bitte den Code verbessern und strukturieren…

(26.02.2024 17:04 )Kaya schrieb:  und falls ja, kann mir jemand erklären, wie das funktioniert?

Es gibt im Example-Finder ein Beispiel namens "Windows Registry Manipulation".

Die Registry hat aber den Nachteil, dass du nur in den Nutzer-spezifischen Teil schreiben darfst (HKEY_CURRENT_USER). Wenn sich ein anderer Windowsnutzer anmeldet, sieht er eigene Werte für deine Parameter. Das kann je nach Fall gewollt (Fensterposition) oder schlecht sein (zB Regelparameter).

(26.02.2024 19:45 )GerdW schrieb:  Stattdessen sollten Programme ihre Config-Daten im Benutzerverzeichnis (unter %userappdata%) ablegen.

Das gilt auch für den Vorschlag von Gerd.

Wenn mehrere Windowsuser dein Programm benutzen sollen, würde ich die ini-Datei im data-Verzeichnis oder einem eigenem config-Verzeichnis im Programmverzeichnis ablegen.

Hallo zusammen,

Zitat:Das gilt auch für den Vorschlag von Gerd.

Es gibt neben %userappdata% auch noch andere Verzeichnisse (die alle von der GetSystemDirectory-Funktion bereitgestellt werden): etliche davon liegen im "Public"-Bereich, auf den alle User Zugriff haben!

MS empfiehlt, (Config-)Daten dort abzulegen...

Danke für Eure Tipps.

Ich habe es jetzt so gelöst.
INI Datei wird im VI zur Verdeutlichung direkt erstellt und dann je nach Auswahl des Tests über einen Eigenschaftsknoten in den VISA Eingang eingelesen.

Das Schreiben in die Datei muss ich mir noch mal überlegen.

LG Kaya

Hallo Kaya,

Zitat:Ich habe es jetzt so gelöst.
INI Datei wird im VI zur Verdeutlichung direkt erstellt und dann je nach Auswahl des Tests über einen Eigenschaftsknoten in den VISA Eingang eingelesen.

- Es fehlt das komplette ErrorHandling.
- Dateien, die man öffnet, sollte man auch wieder schließen!
- Du liest einen String aus der INI-Datei (das ist gut) und wandelst ihn per TypeCast in eine VISA-Referenz: der TypeCast ist unnötig, man kann VISA-Referenzen auch mit einem String beschreiben.

Zitat:Das Schreiben in die Datei muss ich mir noch mal überlegen.

- Auch hier ist der TypeCast unnötig, VISA-Referenzen lassen sich auch an String-Inputs anschließen...
- Auch hier gilt: Datei nach dem Öffnen auch wieder schließen! Und bei INI-Dateien im besonderen: die geänderten Keys auch speichern...
- Ich würde die INI-Datei woanders ablegen, s.o.!

- Eine Wartezeit ist neben einer Event-Struktur mit TimeOut-Event (fast immer) Rube-Goldberg!
- Ein TimeOut-Event ohne Vorgabe der Wartezeit ist immer Rube-Goldberg!

Anzeige