Anzeigestruktur von Ergebnissen auf der GUI - Druckversion +- LabVIEWForum.de (https://www.labviewforum.de) +-- Forum: LabVIEW (/Forum-LabVIEW) +--- Forum: LabVIEW Allgemein (/Forum-LabVIEW-Allgemein) +--- Thema: Anzeigestruktur von Ergebnissen auf der GUI (/Thread-Anzeigestruktur-von-Ergebnissen-auf-der-GUI) Seiten: 1 2 |
RE: Anzeigestruktur von Ergebnissen auf der GUI - Hachiko - 18.07.2024 11:11 (18.07.2024 08:57 )GerdW schrieb: Hallo Hachiko, Hallo GerdW, Ich versuche mit sowenig Drähten wie möglich auszukommen. Díe FGV finde ich für verschachtelte Vis optimal. Ich kenne ein Projekt, da wurde ein Cluster aus Referenzen als Draht durch das ganze Projekt durchgezogen. Muss man mögen, irgendwann finde ich dass es zu viele Drähte sind. Gruß Hachiko RE: Anzeigestruktur von Ergebnissen auf der GUI - Hachiko - 18.07.2024 12:03 (18.07.2024 09:35 )TpunktN schrieb:(18.07.2024 08:52 )Hachiko schrieb: kannst Du mir sagen, welche Palette du benutzt hast. Ich glaube die LV-Profis scheinen keine FGV zu mögen Wenn ich mal Zeit habe, versuche ich es mal ohne FGV. Solange bleibe ich bei meinen alten Vorlagen Die NXG Palette ist muss ich mir mal genauer ansehen. Die hat was. Grüße RE: Anzeigestruktur von Ergebnissen auf der GUI - IchSelbst - 18.07.2024 12:46 (18.07.2024 12:03 )Hachiko schrieb: Ich glaube die LV-Profis scheinen keine FGV zu mögenAlso ich hab nichts gegen FGV's. Kann man gut erweitern um beliebige und theoretisch beliebig viele Funktionen. Entspricht Kapselung von Daten und Programmen. Auch schön: Trennung von Blockdiagramm und User-sichtbares/zugreifbares Frontpanel. Debuggen auch gut. Irgendwer hat mal gesagt, FGVs sind Klassen für Arme. Hab ich nichts dagegen. RE: Anzeigestruktur von Ergebnissen auf der GUI - GerdW - 18.07.2024 13:15 Hallo zusammen, Zitat:Irgendwer hat mal gesagt, FGVs sind Klassen für Arme. Hab ich nichts dagegen.Habe ich zwar nicht (so) gesagt, kann ich aber zustimmen… FGVs sind gut, wenn man ein (1) Datenobjekt verwalten will. Sobald man mehrere dieser Datenobjekte verwalten will wird es kompilizierter - und da kommt dann OOP ins Spiel, das von Haus dieses "mehrere Datenobjekte" abstrahiert. Beispiel: ich brauchte eine Rampenfunktion in einem Programm. Also eine FGV erstellt, die 3 States kennt: Init (mit Rampenhöhe und -dauer), aktuellen Rampenwert (über die Zeit), Ende. Das aufrufende Programm war glücklich und der User konnte seine Rampe ablaufen lassen. 1 Woche später kommt der User: "Ich brauche eine zweite Rampe!" Ups, was nun? FGV kopieren und mit anderem Namen nochmal in Programm packen!? Also doch die Kernfunktion in eine Klasse gepackt und (schwups) beliebige viele Rampen(-Objekte) im Programm möglich… Zitat:Wenn ich mal Zeit habe, versuche ich es mal ohne FGV.Ich selbst nutze auch FGVs - aber nicht, um "unkontrolliert" aus irgendwelchen subVIs heraus Werte zwischen VIs auszutauschen. Das führt dann nämlich auch wieder zu RaceConditions: welches subVI ruft deine FGV schneller auf, um irgendein Element zu updaten! Und wenn es zu viele Aufrufe dieser FGV werden, dann blockieren die sich per Design gegenseitig… (Diese Vorgehensweise ist eigentlich in keiner Programmiersprache empfohlen. Solche Programme sind nur schwer zu dokumentieren, schwerer zu debuggen, usw.) Zitat:Ich versuche mit sowenig Drähten wie möglich auszukommen.Dann solltest du eher eine Text-basierte Programmiersprache verwenden… Im Ernst: auf Drähte zu verzichten führt relativ schnell zu RaceConditions… Du hast doch einen QMH: was spricht dagegen, dass dein MessVI seine Messwerte per Message an den GUI-Handler schickt, der diese Message empfängt und die Werte auf seinem GUI anzeigt? Genauso wie der GUI-Handler Eingaben auf seinem GUI an den QMH schickt, damit der damit seine subVIs aufruft! RE: Anzeigestruktur von Ergebnissen auf der GUI - IchSelbst - 18.07.2024 15:08 Ich sehe, GerdW, wir sind da einer Meinung. Zitat:FGVs sind gut, wenn man ein (1) Datenobjekt verwalten will.Genau 1 Datenobjekt. Nicht zwei, nicht drei. Genau 1. Außerdem: "Verwalten". Eine FGV ist nicht dazu da, primär Drähte einzusparen. Es soll vielmehr alles, was ein Datenobjekt braucht, zentral gesammelt werden. Zitat:Werte zwischen VIs auszutauschenIch finde es tatsächlich eine schlechte Strategie, Daten auszutauschen per FGV. Austauschen und FGV passt einfach nicht zusammen. Austauschen, also "zur Verfügung stellen" und "Befehlen" gehört auch meiner Meinung nach in das QMH-System. Zitat:MessVI seine Messwerte per Message an den GUI-Handler schickt, der diese Message empfängt und die Werte auf seinem GUI anzeigt? Genauso wie der GUI-Handler Eingaben auf seinem GUI an den QMH schickt, damit der damit seine subVIs aufruft!Ein "MessVI" ist ein SubVI, das (ohne FP) im Hintergrund selbständig läuft, also parallel und ohne jedwede Sequenzierung. Es ist praktisch eine selbständige Task. FGVs sind nicht selbständig. Sie sind immer in einen Datenfluss eingebunden. RE: Anzeigestruktur von Ergebnissen auf der GUI - Hachiko - 18.07.2024 15:19 Zitat:Im Ernst: auf Drähte zu verzichten führt relativ schnell zu RaceConditions… Ich glaube, ich bin nicht Profi genug, und die FGV ist einfach anzuwenden. Für meine kleinen Anwendungen ausreichend. Danke für die Erläuterung wie du das machst. Meine Programme werden von mal zu mal besser, vielleicht komme ich irgendwann auch auf eine saubrere Lösung. Schöne Diskussionen in diesem Thread, bin begeistert. Wünsche Euch was. Hachiko |