In ein bestehendes TabControl soll ein weiteres leeres Blatt z.B. an zweiter Stelle eingefügt werden.
Eigentlich ganz einfach, aber egal ob direkt an der zweiten Stelle oder am Ende und an die zweite Stelle verschoben, es ist immer das Bedienelement von Seite 3 darauf und der letzte Tab ist leer (Tab Control).
Bezeichnung ändern, ausblenden, ausgrauen usw. klappt, aber wie bekommt man das hin?
Da die Tabs teilweise im Programm über Enums angewählt werden, soll auch weiterhin TypDef benutzt werden, da sonst bei jeder Änderung die Enums erneuert werden müssen (Tab Control b).
War nicht einfach, dein Problem zu verstehen, aber das Hinzufügen eines neuen Reiters nur in der Typ-Def, das geht halt nicht.
Mögliche, aber funktionierende Lösung:
Du musst das Hinzufügen des neuen Reiters leider 2x machen und nicht nur in der Type-Definition des Controls.
Hierzu wie folgt vorgehen:
- Tab-Control in deinem VI von der Typ-Def trennen.
- Jetzt in der ctl und im VI den neuen Reiter hinzufügen und ctl speichern.
- Tab-Control im VI wieder durch die Typ-Def ersetzen.
Gruß, Jens
Das hatte ich auch schon probiert. Es funktioniert zwar, aber der Red Coercion Dot gefällt mir nicht so.
Bei mir ist kein Coercion-Dot vorhanden.
Gruß, Jens
Mich stört hier nicht so sehr der Coercion-Dot, als vielmehr dass Du für diese einfache Wertzuweisung statt einer lokalen Variablen den hundertmal langsameren Eigenschaftsknoten verwendest...
hier noch ein Einfall:
ich weiß nicht, ob das deinem Problem hilft, aber ich hatte mal einen Fall, in dem ich mit verschiedenen Hardwarekomponenten reden wollte, die jeweils verschiedene Software-Module mit jeweils verschiedenen Registern, die zu lesen/schreiben waren, hatten.
Über einen REQ-Befehl konnte ich mir die in der Hardware verfügbaren Module auslesen und habe für jedes Modul ein eigenes VI erstellt. Das FP des jeweiligen VIs habe ich dann jeweils auf einer Karte einer TabControl als SubPanel eingelinkt.
Dazu habe ich mir eine Registerkarte mit 20 Karten erstellt, die jeweils nur das transparente SubPanel beinhalteten. Dann habe ich so viele Karten eingeblendet, wie ich brauchte und in jedes SubPanel das entsprechende VI eingelinkt. Somit hatte ich eine sich dynamisch an den Komunikationsteilnehmer anpassende Software erfunden, die bis heute supi läuft.
Das FP des übergeordneten VIs, in dem die Registerkarte liegt kann man dann standardmäßig geschlossen setzen und erst öffnen, wenn sich alle Unterkarten aufgebaut haben. Das beschleunigt den Kartenaufbau und sieht nicht so flatterhaft aus.
Gruß, Marko
Jens, bei mir kommt immer ein Coercion-Dot.
1. Front Panel vi - Tab Control -> Disconnect from Type-Def.
2. ctl Datei öffnen -> neuer Tab an zweiter Stelle eingefügt -> Beschriftung angepasst
3. Tab Control vi -> neuer Tab an zweiter Stelle eingefügt -> Beschriftung angepasst
4. ctl gespeichert und geschlossen
5. Tab Control vi -> Replace - Control
6. Coercion-Dot
Stimmt da an meiner Vorgehensweise etwas nicht?
Lucki, Local Variable verwende ich nur bei Read.
Marko, klar ist das eine Möglichkeit. Wenn man aber ein Tab mehr benötigt als eingeplant, steht man wieder vor dem gleichen Problem. Man kann zwar über ein Property Node die beschriftung ändern, mache ich zwar auch (Deutsch/Englisch), aber dann passt die Zuordnung bei Constant nicht mehr.
Irgendwie ist das nicht so gut gelöst.
Wenn man ohne Type-Def. arbeitet, muss man, wenn ein Tab umbenannt wird, alle Constant neu anlegen.
Nutzt man Type-Def gibt es das Problem nicht, kann aber nicht so einfach einen neuen Tab an einer bestimmten Stelle einfügen.
(13.02.2015 08:53 )F.Bi schrieb: [ -> ]Lucki, Local Variable verwende ich nur bei Read.
Dieses Vorgehen würde ich an deiner Stelle überdenken, den jedes Setzen einer PropertyNode "Value" eines Controls erzwingt ein Frontpanel-Update. Wenn du das bei allen Controls machst, bremst du ganz extrem die Performance deines VI aus.
Für das (ab und an) Umschalten eines TabControls geht das aber IMHO in Ordnung, denn auch hier habe ich vereinzelt schlechte Erfahrungen gemacht - das Schreiben per lokaler Variable hat nicht zwangsläufig dazu geführt, dass der Reiter auch wirklich umgeschaltet wurde. Da ist das FP-Update der PropertyNode hilfreich.
Zwecks Coercion-Dot: Ja, genauso habe ich es (wenn ich mich richtig erinnere) gemacht, allerdings ohne das Umbenennen von Reitern.
Gruß, Jens