(18.08.2018 08:42 )GerdW schrieb: [ -> ]Hallo catbull,
ja!
In LabVIEW ist der Draht die Variable!
FP-Elemente dienen als Ein-/Ausgabe...
- Drähte müssen auch über Strukturgrenzen gehen: wie sollen sonst Daten in Schleifen rein/raus?
...mit lokalen Variablen funktioniert das ja auch. Aber klar, dann kann es sein, dass deren Elemente im Weg sind.
Zitat:- Datenkapselung ist durchaus sinnvoll, aber was hat das mit versteckten Anzeigeelementen zu tun?
Wenn ein Element versteckt wird bleibt ja nur der Anschluss im Blockdiagramm übrig und beliebig viele lokale Variablen des Elements. Der Anschluss ist selber dann nichts anderes mehr, als eine lokale Variable. Lokale Variablen bzw. Elemente gelten ja nur innerhalb des Moduls/VIs. Deren Daten sind somit im jeweiligen VI gekapselt.
Zitat:- seit etlichen Versionen kannst du auch Drähten ein Label geben: dann bekommt die "Variable" auch einen Namen...
Das wusste ich noch nicht. Danke. Trotzdem ist es noch nicht das, was ich meine unbedingt zu brauchen. In meinem aktuellen Projekt, ein Spiel in dem ein Luftkissenfahrzeug aus der Vogelperspektive gesteuert wird, gibt es Daten wie Geschwindigkeiten, Kräfte (beides Vektoren in Fornm von komplexen Zahlen) und vieles mehr... Die müssen nirgendwo angezeigt werden, benötigen also kein Element, aber alleine in einem Draht können sie nicht gespeichert werden. Ich brauche ganz normale lokale Variablen -meine ich zumindest.
(18.08.2018 10:42 )Lucki schrieb: [ -> ]Ich gebe zu, dass ich, um den Verdrahtungssalat gering zu halten, gern globale Veriable verwende. Die hier manchmal beschworene geringere Gesschwindigkeit ist eine Mär, das habe ich ausführlich getestet. Man braucht lediglich ein zusätzliches VI, genannt z.B. "global.vi", in dem man alle Variablen, die man verwendeten will, definiert. Da besondere Vorteil ist, dass nicht nur Draht im Haupt-VI wegfällt, sondern auch Anschlüsse an den Sub-VIs. Man kann in jedem beliebig tief verschachtelten SubVI direkt auf die GBs zugreifen.
Das wäre allerdings eine Möglichkeit, die, wenn ich mir mein Projekt anschaue, noch die passendste wäre neben oder nach unsichtbaren Elementen. Du formulierst aber selber schon "Ich gebe zu...". Der Königsweg scheint das nicht zu sein und weil ich eben seit jeher gelernt habe, dass globale Variablen zu vermeiden sind und ich den Gründen dafür auch zustimme, verstehe ich einfach nicht, weshalb es globale Variablen gibt, lokale Variablen aber nur ein Feature von Anzeige-/Bedienelementen sein sollen.
Zitat:Normalerweise werden hier auf so eine Frage mit an erster Stelle Schieberegister genannt. Weiß nicht warum diesmal nicht. Man braucht auch nicht für jede Variable ein eigenes SR (- was wieder auf viel Draht hinausliefe -) , sondern das SR kann ein entsprechend großes Cluster sein, in dem alle benötigten Variablen als Elemente enthalten sind.
Nachdem ich widerwillig mir gerade einige Minuten Gedanken darüber gemacht habe, wie ich das mit Schieberegistern machen könnte ist mir sogar eine Möglichkeit gekommen, die an einigen Stellen funktionieren müsste. Von GerdW weiß ich jetzt auch, dass ich den Drähten zum/vom SR Namen geben könnte. Schmecken will es mir noch nicht, ich werds aber mal versuchen. Danke.
Zitat:Übrigens: Man spart auch dann schon viel Draht und das VI gewinnt an Übersicht, wenn man alle Elemente, die zusammengehören, als Cluster zusammenfasst. Die Clusterumrandung kann man auf dem FP unsichbtbar machen, ja, man kann soger Elemente, die gar nicht zum Cluster gehören, in den Clusterbereich reinschieben. Will sagen: Die Verclusterung zusammengehöriger Elemente muß auf dem FP nicht unbedingt zu einem anderen Aussehen führen, man hat trotzdem noch große Freiheiten im Design.
Jep. Darauf bin ich neulich auch gekommen und habe schon angefangen das so zu machen -notgedrungen wegen begrenzter Anzahl Ein-/Ausgängen der SubVIs. Trotzdem ist ein Cluster ja genauso ein Anzeige- oder Bedienelement das unsichtbar gemacht werden muss, wenn man lediglich die Daten braucht...
(18.08.2018 09:09 )IchSelbst schrieb: [ -> ]Erstens: Ich finde es ein No-Go, und zwar ein absolutes No-Go, wenn man das so sagen kann, Anzeigen/Bedienelemente unsichtbar zu machen. Es gibt einen Grund, sie sichtbar zu lassen: Debugging ...
Zweitens: Selbstverständlich sieht man auch ausgeblendete Elemente - allerdings mehr bei Anfängern und Hobby-Programmieren. Ein Professional wird das kaum machen: Der nimmt die von Gerd aufgelisteten Methoden.
Ich werds versuchen. Da mein Projekt aber keine Scrollbalken haben wird, habe ich mir auch gedacht, vielleicht schiebe ich die Elemente, die nicht angezeit werden müssen, deren Werte ich aber brauche, einfach außerhalb des sichtbaren Bereichs. Dann bleiben sie in der Entwicklungsumgebung sichtbar (zwecks Debugging wie du ja sagst), weil dort die Scrollbalken ja immer angezeigt werden, zur Laufzeit wären sie dann quasi unsichtbar, weil sie außerhalb des angezeigten Bereichs liegen. Wäre das eine Lösung, die noch eher in Frage käme deiner/eurer Meinung nach?
Vielen Dank euch für eure Mühen mit mir. Ich hoffe ich wirke nicht irgendwie stur oder uneinsichtig. Es ist aber wirklich so, dass ich nicht verstehen kann, weshalb es keine lokale Variablen geben soll, so wie es auch globale gibt -also unabhängig von GUI-Elementen. Geht es allen so, die von nicht-grafischen Programmiersprachen zu LV kommen? Wie ich es auch drehe und wende, ich meine, dass lokale Variablen in meinem Projekt am Geeignetsten oder sogar nötig sind. Wie in meinem anderen Thread bezüglich Performanceproblemen angekündigt, werde ich das Projekt an dem ich sitze herzeigen, sobald ich eine "herzeigbare" Version habe. Wenn sich dann der ein oder andere die Mühe machen könnte, mal drüberzuschauen, welche der Alternativen für versteckte Elemente hier die passendste sein muss, wäre ich sehr sehr dankbar dafür...
Ich werde mich aber anstrengen, es selber hinzubekommen. Schieberegister werde ich als erstes versuchen.
So schön sie sind und so einfach sie zu handhaben sind, so lehne ich sie doch aus prinzipiellen Gründen ab: Zum Einen nämlich genau wegen der nicht vorhandenen Datenkapselung und weil sie jeder modularen Programmierung im Wege stehen, zum Anderen aber auch, weil sie anfällig für RaceConditions sind, wenn man sie nicht zu handhaben weiß.