' schrieb:Was ich erreichen will: sobald ein neues Element in die Listen "Ziel 1" oder "Ziel 2" verschoben werden, soll ein Ereignis ausgelöst werden, welches die dann aktuell in der Liste vorhandenen Objekte in ein Array schreibt.
Ja, das hab ich verstanden. Außerdem soll ein Ereignis ausgelöst werden, wenn ein Element herausgeschoben wurde.
Zitat:Was dabei nicht funktioniert: Ich versuche dies über eine Wertänderung des Listenfeldes zu erreichen. Ich bin insofern inzwischen schlauer als dass ich mir bewusst gemacht habe, dass der Wert des Listenfeldes ein Array mit den Indizes der markierten Elemente ist. Wenn sich diese beim Verschieben der Daten nicht ändern, wird mein Ereignis nicht ausgelöst.
Das ist richtig. Und halt, ich sag mal so, ein spezielles Feature von LabVIEW.
Zitat:Ich bräuchte also ein Ereignis, welches direkt registiert, wenn sich das "Objektnamen"-Array der Ziel-Liste ändert.
Das sehe ich auch so.
Zitat:So etwas finde ich in dem Ereignisdialog allerdings nicht.
Stimmt.
Und jetzt ein allgemeiner Kommentar:
LabVIEW ist in erster Linie hervorragend geeignet, Messwerte zu sampeln (mittels Messwertkarten von NI), weiterzuleiten, zu verarbeiten, anzuzeigen, zu speichern. Da musst du andere Systeme schon wie die Nadel im Heuhaufen suchen, die hier NI das Wasser reichen können. Nur ein Stichwort: integrierter DAQmx.
Dafür ist LabVIEW - eigentlich - völlig ungeeignet, was die reine Manipulation von Datenstrukturen angeht wie eben jetzt deine Listen. Hier sind reine OOP-Sprachen, C# sei nur als Beispiel genannt, im Vorteil. Das liegt einfach daran, dass es eben so schöne Events wie OnObjChange etc. etc. etc. in LabVIEW (noch) nicht gibt. Meistens gibt es eben nur den Event "Value changed" (hier muss man natürlich genau wissen, was bei welchem Element (Zahlen, Strings, TabSheets, Listen, Graphen, etc.) jeweils der "Value" ist).
Will man ein Event auf irgendeiner anderen Methode/Eigenschaft liegen haben, muss man entweder suchen, ob denn schon mal jemand was programmiert hat - oder eben selber programmieren. Sprich: auch dein spezieller Fall ist in LabVIEW nur eine Aufgabe, kein Problem.
Lösung:
Deine Aufgabe heißt "in einer Liste steht was, das in ein Array soll". Dieses wolltest du bisher dynamisch lösen: Änderung der Liste => Event => Übernahme nach Array. Eine dynamische Lösung hat den Vorteil, dass sie extrem ressourcenschonend ist (eben wegen des "dynamischen" Events). Es geht aber prinzipiell auch statisch: "Was in der Liste steht wird in ein Array übernommen". Lege ganz einfach das, was jetzt im ValueChgd-Event liegt, in den Timeout-Case, der z.B. alle 250 ms aufgerufen wird - und schon sind alle deine Probleme mit den fehlenden Events gelöst. Diese statische Methode hat zwar den Nachteil, dass sie nicht gerade ressourcenschonend ist. Dafür ist aber das algorithmische Ziel erreicht. Und so kritisch sehe ich das mit den zusätzlichen (Zeit-)Ressourcen in deinem Falle nicht.
Noch ein Hinweise:
Bei der statischen Methode ist natürlich zu verifizieren, dass der verwendete Algorithmus (innerhalb des Timeoutcases) auch tatsächlich "statisch-sicher" ist (ein reines Inkrementieren "Anzahl der Wertänderungen" wäre z.B. nicht "statisch-sicher", weil dann die Anzahl der Timeoutcase-Aufrufe gezählt werden nicht nicht die "Aufrufe ObjChgd-Events").
"Statische Abläufe" unterstützen das Verständnis für "Datenfluss-Steuerung" (in einem Fluss gibt es keine Events).
Ob deine Aufgabe mit LVOOP einfacher zu lösen geht als statisch, weis ich nicht. Ich mach kein LVOOP.
Zitat:Das ist sicherlich der sauberste Weg. Nur habe ich derzeit ein konkrete, recht umfangreiche Aufgabenstellung und muss es irgendwie bewerkstelligen die nötigen Funktionen von LabView im Kontext zu erlernen.
Da sind wir natürlich beim Hauptproblem aller arbeitenden Programmierer. Der Chef verlangt "mach das, aber ohne Kosten zu verursachen". Viel Spaß mit LabVIEW.
Und: Die SubVis kuck ich mir auch noch an. - Später.
