flexible DropDown-Menüs zur Tabellenfilterung

Guten Morgen zusammen,

ich erstelle für meine Abschlussarbeit ein Berechnungsmodell für eine hydraulische Anlage mit variierenden Anlagenteilen, welche vom Anwender ausgewählt werden können. Die zur Verfügung stehenden Teile sind in einer csv-Tabelle hinterlegt und können über Menüringe aus der Tabelle "gefiltert" werden, dabei sind die Auswahlmöglichkeiten der Ringe voneinander anhängig. Eine weitere Besonderheit ist, dass nicht genau ein bestimmtes Teil ausgewählt werden muss, sondern auch ein stellvertretendes für eine bestimmte Gruppe an Teilen gewählt werden kann. Ich habe mal mein momentanes VI mit Beispieldaten (ohne externe Tabelle) angehängt. Der Nutzer kann zB genau das runde Teil 11 vom Hersteller 1 usw. auswählen, oder aber eins das für alle runden Teile des Hersteller 1 steht.
Nun zu meinem momentanen Problem. Klickt man sich durch die Menüs und wählt zB Adapter 1 - Hersteller 1 - Rund - Teil 22 und wechselt dann im Menü "Art" von Rund zu Eckig möchte ich, dass das Menü "Name" nicht <5> anzeigt sondern auf den ersten Eintrag "leer" gesetzt wird. An anderer Stelle ist mir dies schon über die Case-Strukturen gelungen, ich habe es auch geschafft mein Ziel über die Verwendung einer Event-Struktur zu erreichen, was mir aber nicht besonders elegant und etwas "riskant" vorkam. Über Vorschläge oder einen generell besseren bzw. effizienteren Lösungsansatz würde ich mich sehr freuen. Für Rückfragen und Kritik stehe ich gerne zur Verfügung

Grüße
Thomas


  VI_dropdown_beispiel.vi (Größe: 37,7 KB / Downloads: 160)


  VI_dropdown_beispiel12.vi (Größe: 17,06 KB / Downloads: 171)

Hallo Thomas,

herzlich willkommen im Forum!

Zitat:An anderer Stelle ist mir dies schon über die Case-Strukturen gelungen, ich habe es auch geschafft mein Ziel über die Verwendung einer Event-Struktur zu erreichen, was mir aber nicht besonders elegant und etwas "riskant" vorkam.

Was an einer Event-Struktur soll unelegant und riskant sein?
Eine Eventstruktur würde dein VI deutlich aufwerten…

Allgemeine Hinweise:
- Deine ganze Menüauswahl ließe sich auch über eine Datenbank-Anwendung realisieren: "Gib mir alle Datenbankeinträge, für die folgende Kriterien gelten…"
- Setze deine verschiedenen Menü-Ringe immer in Abhängigkeit der anderen Auswahlen, genau wie bei der Datenbank: "WENN Hersteller=1 DANN nur noch Serie1/2 möglich"
- Die Auswertung der Menüeinträge lässt sich wunderbar in einem ValueChange-Eventcase erledigen!
- Eine andere Möglichkeit, solche "Menüs" zu präsentieren, wären Tree-Controls. Hier musst du im Vorfeld deine Daten entsprechend aufbereiten und strukturieren…
- Ich finde auch Listboxen schön, die dynamisch angepasst werden: man benötigt nur etwas mehr Platz auf dem UI als bei Menü-Ringen…

P.S.: Ich finde es super, dass du dein VI auch gleich für ältere LV-Versionen bereitstellst. Bitte gern weiter so!

Hallo Gerd,

danke für die Begrüßung und die sehr schnelle Antwort!
Ich hatte eine Event-Struktur in der Case-Struktur und über die Timeout-Funktion dafür gesorgt, dass das Programm nicht in dem Event "hängenbleibt", das wirkte sehr unsauber auf mich..

Eine Auswahl der Einträge ähnlich einer SQL-Abfrage wäre natürlich schön simpel. Ist das mit LabVIEW realisierbar, ohne großartig eine Datenbank aufzusetzen und auf zusätzliche Tools zurückzugreifen? Das spätere Programm soll wenn möglich mit csv-Tabelle und Ausführungsdatei auskommen.

Da am Ende insgesamt zwölf verschiedene Teile ausgewählt werden können, halte ich die Menü-Ringe bisher für am übersichtlichsten bzw. vllt auch am optisch ansprechendsten.

Ich werde mich nochmal an der Event-Struktur versuchen, die Abhängigkeiten über Cases darzustellen sollte aber in Ordnung gehen oder? Also für jedes Menü ein ValueChange-Event und dafür entsprechende Cases definieren.
Das VI wollte ich später als SubVI in einer Art Zustandsautomaten verwenden...dazu werden dann sicher auch noch einige Fragen kommen

Hallo Thomas,

Zitat:Ich hatte eine Event-Struktur in der Case-Struktur und über die Timeout-Funktion dafür gesorgt, dass das Programm nicht in dem Event "hängenbleibt", das wirkte sehr unsauber auf mich..

Ja, da gebe ich dir recht!
Eine Eventstruktur sollte nicht in einem Case versteckt werden: schau dir doch mal die BeispielVIs zum Thema Events an…

Zitat:Ist das mit LabVIEW realisierbar, ohne großartig eine Datenbank aufzusetzen und auf zusätzliche Tools zurückzugreifen?

Ich bezog mich da schon auf eine "echte" Datenbank…

Zitat:Da am Ende insgesamt zwölf verschiedene Teile ausgewählt werden können, halte ich die Menü-Ringe bisher für am übersichtlichsten bzw. vllt auch am optisch ansprechendsten.

- 12 Menüringe snd schon eine ganze Menge…
- ich finde ja die Controls aus der Systempalette deutlich "hübscher" aka "optisch ansprechender"

Zitat:Also für jedes Menü ein ValueChange-Event und dafür entsprechende Cases definieren.

Ja, für jedes Menü ein Event.
Nein, nicht jedesmal alle möglichen Cases definieren: erstelle dir diese Menü-Ring-Konfiguration genau einmal. Diese Konfiguration wird nach jedem Event (wenn nötig) aufgerufen. Die einzelnen Menüauswahlen würde ich in einem Cluster zwischenspeichern, der wiederum in einem Schieberegister gespeichert wird, damit man in jedem Event/Case darauf zugreifen kann:
   

Interessante Idee mit dem Cluster...werde da mal etwas mit rumdoktorn.
Vielen Dank schon mal bis hierhin!

(13.12.2016 10:14 )GerdW schrieb:  - ich finde ja die Controls aus der Sysempalette deutlich "hübscher" aka "optisch ansprechender"

Flat-Style Controls, unabhängig von der Windows-Version...
IMHO aktuell das beste kostenlose UI-Set.

Gruß, Jens

@GerdW
Hm also die aktuelle Menüauswahl in dem Cluster zu speichern ist ja schnell gemacht, aber ansonsten hat sich mir dein Ansatz noch nicht ganz erschlossen..
Was schließe ich denn an den Case-Selektor an? Bzw. wie bestimme ich anhand der Konfiguration, welcher Case ausgeführt werden soll? Vielleicht kannst du mir da nochmal einen zweiten Fingerzeig geben wie du dir das gedacht hast, im Moment bin ich jedenfalls etwas verwirrt

Hallo Thomas,

Zitat:Hm also die aktuelle Menüauswahl in dem Cluster zu speichern ist ja schnell gemacht, aber ansonsten hat sich mir dein Ansatz noch nicht ganz erschlossen..

Mit den Daten im Cluster kannst du für jeden Menüring dein 2D-Array filtern und passende Einträge festlegen.
Jetzt nur noch einmal eine Funktion programmieren, die dein großes 2D-Array mit den ganzen Daten entsprechend filtern kann…

(Wenn ich darüber nachdenke, könntest du auch ein 1D-Array of strings verwenden. Der Cluster bietet "nur" den Vorteil, "lesbare"/selbsterklärende Elementnamen für (Un)BundleByName zu verwenden.)

Zitat:Was schließe ich denn an den Case-Selektor an?

Dort kann z.B. eine Bedingung angeschlossen werden, die festlegt, ob die Menüeinträge überhaupt neu gefiltert werden müssen.
Deine Event-Struktur kann ja noch viele weitere Events abarbeiten, z.B. TimeOut, PanelClose oder einen Stopp-Button…

Da bin ich wieder,

habe es immerhin geschafft die Zahl meiner For-Schleifen bei der Filterung zu drücken. Ich muss ja erst anhand der ersten drei Menüs filtern, dann das vierte Menü füllen und schließlich komplett filtern...naja
Eine Bedingung, dass nur neu gefiltert wird wenn sich ein Wert geändert hat konnte ich noch nicht realisieren. Ansonsten habe ich mich wieder in meinen Case-Strukturen verlaufen
Ich weiß nicht wie ich die Abhängigkeiten der Menüs voneinander sonst realisieren sollte, aber die momentane Version funktioniert leider auch nicht. Vielleicht gibt es ja jemanden der noch nichts für den Abend geplant und und sich das gerne mal anschauen möchte
Wird ein Menü verändert sollen die dahinterliegenden Menüs im Zweifel auf "leer" gesetzt werden, wenn Anschluss offen ausgewählt ist soll nicht Hersteller 1 zur Verfügung stehen usw...
Nochmal vielen Dank für die bisherige Hilfe, ich setze mich dann morgen wieder dran!

Grüße
Thomas


  VI_dropdown_beispiel_rev2.vi (Größe: 41,29 KB / Downloads: 146)


  VI_dropdown_beispiel_rev2_12.vi (Größe: 18,84 KB / Downloads: 154)