(21.07.2016 08:39 )Freddy schrieb: aber einen Nachteil hat es schon, Du musst bei jedem Aufruf des SUB VI die Anzeige Daten und Eingabe Daten neu füllen
Das sehe ich nicht als Nachteil (infolgedessen ich keine Subpanels verwenden würde).
Das Befüllen ist ein Teil des Algorithmus und somit integraler Bestandteil eines jeden VIs. Das Anzeigen von Daten geht bei mir sowieso online, also kontinuierlich: da spielt die Tatsache, dass das VI gestartet werden muss, keine Rolle. Auch das Befüllen der Eingabefelder ist sowieso vorhanden, auch ohne Subpanel.
Genereller Hinweis:
So Argumente wie "Der Rechner verbraucht doch aber Zeit und Speicher" sind voll die 1990 ...
Zitat:und dafür parallele Daten halten.
Diese Argument wäre dann richtig, wenn ich so kompliziert programmieren würde, dass dieser Fall einträte ...
Dem ist aber nicht so: Die Daten, mit denen gearbeitet wird, liegen (samt deren Methoden) z.B. in einer FGV. Das FP dient lediglich als Anzeige; mit den "Anzeigedaten" wird nie gearbeitet. Um auch gleich die nächste Frage zu beantworten: Die Daten werden nicht in dem VI, das das Anzeigeelement enthält, in die Anzeige geschrieben. Das VI übergibt bei VI-Start eine Referenz an die FGV, die dann, wann immer es notwendig ist, die Daten in das Anzeigeelement schreibt. Neben FGV gibt es auch noch Melder, die Daten halten können. Daten in Melder muss das VI aber selbst in die Anzeige bringen.
Für Eingabeelemente gilt analoges: Eine Eingabe durch den Anwender bewirkt einen Event, in dem der komplette Cluster (und wehe einer arbeitet mit einzelnen Eingabefeldern...) in die FGV geschoben wird. Usw.
Zitat:Ich verwende den Tab-Control als schnellen Wechsel der Frontansicht ohne Reiter mit transparenten Hintergrund.
Es muss selbstverständlich ein Optimum gesucht werden zwischen "alles in einem VI" und "aufgeteilt in SubVIs". Hauptkriterium ist die Komplexität des BD, nicht die des FP. In einem BD soll so wenig wie möglich stehen (weiterer Vorteil: Kein Code - kein Fehler). Selbstverständlich hab ich in einem Subpanel-VI (verschachtelte) Tab-Controls mit vielen Tab-Sheets - die sind aber hauptsächlich nur zur Anzeige.
Zitat:So wechsel ich z.B. von einem Graph in die Eingabe oder was auch immer.
Nur alleine das Wechseln von Tab-Sheets ist tatsächlich kein Grund, Subpanels zu verwenden.
Ein Grund wäre: Auf einem Tab-Sheet wird ein zugeordneter, sich im BD befindender Algorithmus ausgeführt, der aber immer nur dann ausgeführt wird, wenn auch dieses Tab-Sheet aktiv ist. Wenn es mehrere solcher Tab-Sheets gibt, dann sollte für diese Tab-Sheets ein Subpanel verwendet werden. Dann nämlich liegt das BD in einem SubVI und das Main-VI wird automatisch kleiner.
Zitat:Allerdings sind bei mir bisher die TABs nicht zu viele gewesen.
Kriterium ist nicht die Komplexität (also wenige Elemente) des FP, sondern die des BD ...
Zitat:Da hätte ich noch ein paar Fragen:
Ach, das obere waren gar keine Fragen?
(<=
)
Zitat:Hättest Du mal ein kleines Beispiel, wie Du die SUB VI's im Main behandelst? Vor allem mit Datenübernahme.
Müsste ich erst eines machen ...
Handling ist ganz einfach: Das SubVI wird per VI-Server gestartet und dem Subpanel zugewiesen. Als Parameter gibt es lediglich eine Boolsche Variable "StandAlone", die besagt, ob das VI standalone läuft ober vom Hauptprogramm aufgerufen wurde. Daten liegen bei mir ja hauptsächlich in FGVs (und Meldern) und müssen somit nicht an der VI-Schnittstelle übergeben werden. Hinweis: Über Benutzer-Events kann das SubVI von extern beendet werden.
Zitat:Und wo läuft die Event Schleife im Main oder in den SUB VI?
Die welche? Grundsätzlich läuft in jedem VI eine Event-Schleife.
/
Mehrere Registerkarte in Queue Message Handler entwerfen.
