Eigenschaftsknoten korrigiert Eigenschaft nicht

Guten Morgen zusammen,

ich versuche seit zwei tagen einmalig eine Tabelle mit Checkboxen zu erstellen.

Dazu wollte ich zunächst eine mehrspaltige listenbox mit samt definierten spalten- und reihen Größen einmalig erstellen. Jedoch stellte ich fest das es über das Frontpannel keine Funktion ähnlich Excel gibt wo man die breiten und höhen über Zahlenwerte festlegen kann kann.

Daher bin ich direkt zu naheliegendsten alternative über programmatische Formatierung über Eigenschaftsknoten an die Sache ran gegangen

Leider bin ich dabei auf ein Problem gestoßen:
Der Eigenschaftsknoten wendet Änderungen der über ihn definierten Eigenschaften nicht noch einmal an, sobald er diese einmal umgesetzt hat.
Wir arbeiten zu dritt an dem Messplatz und werden alle mal hier und da kleine Änderungen vornehmen, weswegen das Programm bis auf weiteres in der LV Umgebung laufen wird.

Konkret habe ich jetzt also das Problem das ich zwar beim ersten initialisieren der Eigenschaften über den Eigenschaftsknoten, die mehrspaltige Listbox das gewünschte Format annimmt, aber nach nachträgliche Änderungen, bei nicht ausgeführten Programm (z.B. die beim ungeschickten huschen über das Frontpannel, im speziellen ungewolltes vergrößern/verkleinern der spalten) dazu führt, dass die Änderung beibehalten wird. Dieses Verhalten wird leider auch beim speichern übernommen, sprich selbst nach schließen und wieder offenen des VIs wird sich immer noch geweigert die Formatierung wie angegeben umzusetzen.

Der Eigenschaftsknoten wendet die Formatierung also nur einmal an bis sich seine Vorgabe ändert. Ändere ich aber die Vorgabe auf eine leicht andern wert, wird diese plötzlich umgesetzt, die ursprünglich wird jedoch nicht beibehalten obwohl der Eigenschaftsknoten doch registrieren sollte das Eingabe nicht gleich Ausgabe ist (wenn er das überhaupt müsste, ich hätte erwartet das er die Formatierung einfach stumpf umsetzt).

Ich such jetzt also seit zwei tagen entweder den Eigenschaftsknoten dazu zu bewegen seine Aufgabe zu erfüllen oder irgendwie die Änderung des Listbox Formates zu sperren ohne die gesamt Bearbeitung des Inhaltes zu sperren, denn dies muss für den weitern Verlauf erhalten bleiben.

Ich habe ein Beispiel .vi angehängt und hoffe jemand kann dies nachvollziehen und hat ein Lösung parat. (Falls eine Version für andre LV Versionen benötigt wird, bitte kurz beschied geben)

hier die schritte um das Problem nachzuvollziehen:
1. öffnen -> ausführen.
2. beliebige Breit/Höhe einer Zelle/Titels, manuell mit der Maus, ändern.
3. Erneut ausführen (Format wird nicht zurück gesetzt).
4. geänderten Größenwert um einen Pixel ändern.
5. erneut ausführen (Format wir nun angewendet).

Vielen Dank für eure Bemühungen

Bearbeitung 22.03.2017 10:27 - Typo
24.0302017 19:02 - Verdeutlichungen

Hallo ksanto,

Zitat:Ich such jetzt also seit zwei tagen entweder den Eigenschaftsknoten dazu zu bewegen seine Aufgabe zu erfüllen

Ich konnte den Fehler nachvollziehen, die Porperty wird erst nach Änderung ihres Werts übernommen.

Workaround: Die Eigenschaft zweimal setzen und dabei die Werte beim ersten mal geringfügig ändern! Mit DeferPanelUpdates sieht man davon dann nicht einmal etwas…

Hallo Gerd,

danke für die schnelle Antwort. Sowas in der Art hatte ich mir auch schon überlegt, jedoch fand ich das sehr unbefriedigend weil ich mir einfach nicht vorstellen kann das dass verhalten so von dem abweicht was ich (und scheinbar auch der durchschnittliche LV User) erwarten könnte. Ich wollte natürlich auch nicht gleich BUG!! schreien.
Daher ging ich davon aus ich würde bei meiner eher mäßigen Erfahrung mit LV etwas nicht wissen.

Trotzdem, der Tipp mit DeferPanelUpdates macht es natürlich hübscher, Danke.

Es scheint offensichtlich mit dem Index -2 (= alle Zeilen bzw. Spalten) zu tun zu haben. Wenn man die Zeilen/Spalten explizit adressiert, so klappt die Formatierung immer. Ein Workaround wäre also per Schleife alle Spalten und Zeilen zu "refreshen", aber ich denke, da ist Gerds Lösung einfacher.

Hallo THL,

Ja das dachte ich mir auch, aber ich muss zugeben das ich dass erst Garnichts Probiert hatte. Als ich es dann aufgebaut hatte habe ich es erstmal ohne DeferPanelUpdates probiert und erwartete (wahrscheinlich genau wie Gert) das es flackert.
Tut es aber nicht, deswegen mach ich das jetzt erstmal bis auf weiteres ohne.

Ich kenne den Effekt, allerdings habe ich das in den letzten 3 Jahren nicht mehr beobachten können. Dehalb nehme ich an, dass der Fehler bei den neueren Versionen von Labview beseitigt wurde. Ich kann auch jetzt den Effekt im Beispiel nicht reproduzieren, weder mit LV2015 SP1 noch mit LV2016.
Es wäre deshalb nicht schlecht, wenn hier noch mehr Forumsmitglieder das Beispiel prüfen würden.

Anzeige

Hallo Lucki,

dass must du mir jetzt aber mal aufdröseln. Wie kannst du annehmen das der Fehler in neueren Versionen von Labview beseitigt wurde?
Offensichtlich habe ich Version 2016 vor mir und die ist sogar voll gepatcht. Ich hab ja auch ein Version des Problemcodes von aus 2016 angefügt.

Sorry wenn es jetzt so klingt als würde ich den grammar-Nazi rauskehren, aber ich überlege ob hinter der Aussage irgendwas steh was ich nicht lesen kann.

Es ist aber in der tat merkwürdig das du als erster eindeutig bestätigen kannst das es bei dir kein Probleme gibt.
Langsam wird das Thema doch interessanter als zu vermuten war.

Bearbeitung 23.03.2017 21:01 - Typo

Ich konnte das auch unter LV 2016 nachvollziehen. Sobald was interaktiv geändert wurde, wurde bei der nächsten Ausführung trotzdem nicht der gewünschte Zustand wieder hergestellt.

Gruß, Jens

Dieser "Bug" ist ja auch irgendwie verständlich. Es tritt ja auf, wenn man bei der Zeilen-/Spaltenauswahl den Index -2 nimmt, d.h. *alle* Zeilen bzw. Spalten auswählt. Wenn man jetzt interaktiv z.B. die Breite einer Spalte ändert und danach den Eigenschaftswert mit Index -2 (= alle Spalten!) ausliest, was soll da Labview als Zahlenwert zurückliefern? Programmtechnisch ist es wohl am simpelsten einfach den ursprünglichen Wert zu nehemen und auf irgendwelche händischen Änderungen zu pfeifen. Mit anderen Worten: Egal wieviel man per Hand herumformatiert - intern behält Labview die ursprüngliche Breite/Höhe für diesen Eigenschaftswert (was soll er auch sonst nehmen). Und wenn man genau diesen gespeicherten Wert jetzt erneut setzt, greift halt die Labview-Logik "löse ein Ereignis aus, wenn der Wert sich geändert hat" - und das hat er in diesem Fall halt nicht.

Ich habe mal das Beispiel in eine Schleife gesetzt und ändere fortwärend die die Breite. Die Breite wird zusätzlich numerisch angezeigt. Bei mir stimmt die Breite immer mit der numerisch angezeigten Breite überein, d.h. die Eigenschaft wird immer sofort ausgeführt. Bei allen anderen Teilnehmern an dieser Diskussion dürfte das dann nicht so sein, wenn ich Euch richtig verstanden habe.