Aufbau Frontpanel mit sehr vielen Tabs, speichern aller Parameter in XML

(15.02.2011 10:50 )mikeee schrieb:  Gut, es muss also nicht reentrant sein.

es darf nicht ...

Zitat:Scheint mir klar, da sonst das VI mehrfach gleichzeitig laufen kann und dadurch der Trick entfällt

Letztendlich hast du recht. Nur: was meinst du hier mit Trick?

Zitat:Habe in diesem Zusammenhang nochmals über die Semaphore nachgedacht und festgestellt, dass es so wie ich wollte völliger quatsch ist.

Zitat:(d.h. ich kann direkt eine Untermenge der Daten ändern ohne davor Daten lesen zu müssen)

Das läuft auf "atomar gekapselt" hinaus.

Zitat:Ein VI mit einem Eingang für jeden dieser Sätze (COMOptionen, CANOptionen)

Nachteil: Beschränkung durch Anzahl der Eingänge.

Zitat:Ein polymorphes VI (eigene Abhandlung für COMOptionen Cluster und für CANOptionen Cluster) das dann wieder auf immer die selbe FGV zugreift

Nachteil: im (polymorphen) VI muss das FGV aufgerufen werden => Variante 1

Zitat:Ein VI mit Variant als Eingang für die Datensätze und einem Eingang um die Funktion zu steuern.

Zitat:Jetzt frage ich mich bei Variant: ...

Die einfachste Lösung ist Version 3: Variant + Fkt.
Alle anderen Versionen sind mit Mehraufwand verbunden. Du müsstest, grob gesagt, den Datencluster und den Typ des Datencluster zu einem neuen Typ zusammenfassen und dieses dann als Variant übergeben. Auf der anderen Seite (der Schnittstelle) müsstest du per Case-Anweisung den Eingangsvariant wieder decodieren. Besonders letzteres ist mit relativ viel Aufwand verbunden. Mit Fkt wird der "Typ der Daten" quasi explizit übergeben.
Vorteil der Funktion ohne Fkt: Vom Grundsatz scheinbar besser scalierbar. Nur ein Parameter.
Vorteil der Funktion mit Fkt: wesentlich einfacher - vor allem aber ausreichend für die Anwendung. In wie weit diese Version gut scalierbar ist, ist eine andere Frage.

Zitat:Den Datenausgang halte ich wohl als Cluster, gebe immer alles aus und trenne dann mit "Unbundle by name".

(15.02.2011 09:50 )macmarvin schrieb:  Klar kann man reentrante FGVs nicht per statischer Referenzierung (VI auf Blockdiagramm) sinnvoll einsetzen. Da muss man zwingend über dyn. geöffnete VI-Referenzen und Call by Reference Node arbeiten. Das ist die eine, meiner Meinung nach schönere Möglichkeit die Skalierbarkeit von FGV basierten Stukturen/Architekturen zu erhöhen.

ja okeh, sowas mach ich aber nur bei wirklich "großen" FGVs die z.B. ein "Treiber-Objekt" darstellen sollen, und ich das "Objekt" mehrfach brauche. Das ist aber auch - nach meiner Auffassung - schon keine FGV im klassischen Sinne mehr, sondern ehr schon sowas wie ein "Möchtegern-Objekt"

(15.02.2011 09:50 )macmarvin schrieb:  Die wäre die FGVs intern so zu erweitern, daß sie verschiedene "Instanzdatensätze" verwalten kann, finde ich unschön und sorgt mglw. für unerwünschte bzw. unwertartete Synchronisierungspunkte.

ACK, mach ich und mag ich auch nicht (bis auf eine Ausnahme - in meinem ADO-Tool)

Thema Race-Conditions: ja, im Sinne von kein paralleles Lesen/Schreiben möglich

Danke danke danke, jetzt ist alles viel klarer!

Gut, dann nochmals zu den Funktionen. Nur damit ich sicher bin, dass ich das alles in die FGV stecken kann.

- Daten schreiben (jeweils für jeden Satz eine eigenen Schreibfunktion)
- Daten lesen (da kommt einfach alles in einem Cluster heraus)
- lock (man kann nur noch lesen, das ist aktiv, wenn der Test läuft, damit nichts mehr an den Einstellungen geändert werden kann. Gleichzeitig werden über diesen Zustand die Subpanels Grey-out, damit nichts geändert werden kann)
- unlock (um die Einstellungen wieder freizugeben, sobald der Test beendet wurde)
- GetIfLocked (um damit die Subpanels greyouten)
- Daten in XML schreiben
- Daten von XML lesen

Wenn ich jetzt Daten vom File lese, muss ich das den SubPanels irgendwie mitteilen, damit diese ihre Controls updaten und nicht etwa wieder die alten Daten in die FVG schreiben. Soll ich da über eine Queue allen SubPanels eine Nachricht senden (Achtung Leute liest mal die Daten neu ein!)? Oder wie macht ihr das?

Wie mache ich das mit dem schreiben auf die FGV? Die SubPanels laufen ja alle auch wenn sie gerade nicht angezeigt werden, also auf einem Tab liegen, der gerade nicht im Vordergrund ist (oder?). Wenn ich jetzt einfach bei jedem Schleifendurchgang (z.B. alle 100ms) alle SubPanels immer ihre Daten von den Controls in die FGV schreiben lasse ist das ja völliger quatsch. Kann ich da irgendeinen Event generieren oder muss ich auf jedes SubPanel einen WriteButton platzieren (ginge schon aber irgendwie finde ich das nicht so Benutzerfreundlich).

Habe jetzt auch ziemlich lange nach einer Option gesucht das ganze SubPanel zu blockieren und grau alle Controls grau zu hinterlegen... Habe aber keine entsprechende Property gefunden. Weiss jemand wie man das am schlausten macht?

(15.02.2011 12:35 )mikeee schrieb:  - lock (man kann nur noch lesen, das ist aktiv, wenn der Test läuft, damit nichts mehr an den Einstellungen geändert werden kann.

Die Funktion heißt also LOCK. Hier wird intern ein Flag gesetzt, das "Daten schreiben" in der FGV unterbindet.

Zitat:- GetIfLocked (um damit die Subpanels greyouten)

Diese Funktion ist an sich überflüssig.
Trick: (D)Eine FGV hat neben dem Datenausgang einen Statusausgang. Will das TabSheet wissen, ob die Daten ausgegraut werden sollen, wird der Status abgefragt.

Je nach Lust und Aufwand geht auch folgendes:
Übergib der FGV pro Datencluster eine Referenz auf das entsprechende Anzeige/Eingabe-Element. Jetzt kann der LOCK/UNLOCK-Befehl die entsprechenden Elemente entsprechend manipulieren. Das SubVI, das im SubPanel ausgeführt wird, hat somit keinerlei Aufwand mit enable/disable.

Zitat:Wenn ich jetzt Daten vom File lese, muss ich das den SubPanels irgendwie mitteilen, damit diese ihre Controls updaten und nicht etwa wieder die alten Daten in die FVG schreiben. Soll ich da über eine Queue allen SubPanels eine Nachricht senden (Achtung Leute liest mal die Daten neu ein!)? Oder wie macht ihr das?

Per Referenz.

Beachte folgendes:
Das Programm wird ja stäter von einem Anwender benutzt. Der kann aber immer nur einen Reiter eines TabSheets sehen. Demzufolge auch immer nur ein SubPanel. Es liegt also nahe, dass auch nur ein einziges SubVI aktiv ist. Viele SubVIs in vielen SubPanel, die auf die FGV zugreifen wollen, gibt es also gar nicht. Demzufolge muss also niemandem mitgeteilt werden, dass jetzt Daten zu refreshen sind.
Bei mir geht das so:
Es gibt ein HauptVI, das das Registerkartenelement enthält - und auch nur dieses. Die einzelnen Reiter sind leer! Das einzige, was man sieht, sind die Schaltflächen der Reiter. Unterhalb des Registerkartenelements gibt es ein einziges SubPanel. Bei Klick auf einen Reiter wird das dem Reiter zugeordnete SubVI ausgeführt. Und das erste, was das SubVI macht, ist, das Anzeige/Eingabe-Element entsprechend dem LOCK-Status zu manipulieren. Da alle anderen SubVIs gar nicht laufen, gibt es auch keine Notwendigkeit deren Elemente zu manipulieren ...


Damit entfallen alle deine aufgezeigten Probleme.


Nachtrag:
Ich sag mal so: Ob ein "FGV" "einfaches SubVI" oder "MöchteGern-Klasse mit gekapselten Daten und Propertys" genannt wird, ist mir eigenlich egal. Wichtig sind die gekapselten Daten. Die Möglichkeit von Propertys ist ideal. Warum also nicht "MöchteGern-Klassen" verwenden?

danke, das hat mir sehr geholten. Habe jetzt mal den grössten Teil programmiert. Alle Masken stehen und auch das Grundgerüst der FGV.

Was meinst du mit per Referenz. Heisst das die FVG soll sich die Daten über eine Referenz selbst von den Panels holen und auch darauf schreiben? Dann bräuchte ich eigentlich auch keinen Eingang an der FGV. Die würde sich halt immer alles selbst abholen... Dann habe ich auch keine Synchonisationsprobleme. Wenn ich zum Beispiel Daten von einem File lese schreibe ich die einfach gleich in die Controls. Wenn ich Daten ins File schreiben will hol ich mir die selbst und schreibe.

Mal ein kleine Anmerkung am Rande der Diskussion. Wenn alle Daten, die Du speichern willst, in einem Cluster (der auch kompliziert sein kann) zusammengefasst sind, dann kann man das Speichern (in editierberer Form) und Lesen ganz einfach mit einer INI-File besorgen - ohne daß man dazu noch Programmieraufwand betreiben muß.
In OpenG gibt es dazu die beiden "VIs Read INI Cluster" und "Write INI Cluster" - die sind intern höchst komplex und machen das alles.
   

Anzeige

Das ist ein guter Hinweis Lucki, das brauche ich nämlich auch noch. Allerdings würde ich XML vorziehen. Gibt es das selbe auch mit XML?

Wie fehlertolerant ist das einlesen solcher Files. Wenn im File gewisse Angaben fehlen (z.B. ein Subcluster komplett fehlt) kann ich dann festlegen, dass dafür einfach Defaultwerte eingesetzt werden oder funktioniert das ganze dann nicht?

Es muss möglich sein nicht komplette und sogar fehlerhafte (von Hand erstellt mit Tippfehler z.B.) Files einzulesen ohne dass dies zu einem unvorhersehbaren Verhalten führt.

(17.02.2011 12:59 )mikeee schrieb:  Was meinst du mit per Referenz. Heisst das die FVG soll sich die Daten über eine Referenz selbst von den Panels holen und auch darauf schreiben?

Hm. Klar. Wenn schon "schreiben nach" geht natürlich auch "lesen von" ...
Das Lesen/Schreiben würde aber nicht auf Initiative der FGV gehen, sondern auf Initiative des Anwenders im entsprechenden SubVI/TabSheet/Reiter/CLuster. Dort wird dann festgelegt, dass die FGV jetzt arbeiten soll.

Zitat:Dann bräuchte ich eigentlich auch keinen Eingang an der FGV.

Zumindest für die Daten bräuchtest du dann keinen Eingang. Zum Übergeben der Referenzen an dir FGV schon.

Zitat:Dann habe ich auch keine Synchonisationsprobleme.

Zitat:Es muss möglich sein nicht komplette und sogar fehlerhafte (von Hand erstellt mit Tippfehler z.B.) Files einzulesen ohne dass dies zu einem unvorhersehbaren Verhalten führt.

Das geht mit INI natürlich problemlos. Inis haben halt den Nachteil, dass die aufwändiger zu programmieren sind (als XLM, weis nicht genau, mach ich nicht).

(17.02.2011 15:28 )IchSelbst schrieb:  

(17.02.2011 12:59 )mikeee schrieb:  Was meinst du mit per Referenz. Heisst das die FVG soll sich die Daten über eine Referenz selbst von den Panels holen und auch darauf schreiben?

Hm. Klar. Wenn schon "schreiben nach" geht natürlich auch "lesen von" ...
Das Lesen/Schreiben würde aber nicht auf Initiative der FGV gehen, sondern auf Initiative des Anwenders im entsprechenden SubVI/TabSheet/Reiter/CLuster. Dort wird dann festgelegt, dass die FGV jetzt arbeiten soll.

Ja auf Initiative des Benutzers klar. Ich dachte das so: Der Benutzer startet den Test über einen Button, damit wird der FGV der Befehl gegeben alle Werte aus den Controls zu lesen. Gleichzeitig graue ich alle Controls aus (von der FGV aus gesteuert).
Wenn ich von einem File lese gibt es dazu auch einen Button: FVG kriegt Auftrag File zu lesen, tut dies und schreibt alles in die Controls.
Wenn ich in ein File schreiben soll: FGV kriegt den Auftrag, liest alle Controls, schreibt das File.


Gibt es keine Möglichkeit eine statische Referenz zu verwenden? Geht wohl nicht weil das einzelne Programme sind, die halt nicht gelinkt sondern nur dynamisch zu Laufzeit gekoppelt werden und dann weiss ja vorher keiner wo das im Speicher liegen wird... sehe ich das richtig?


INI-Files sind aufwändiger als was? Binäre Files?

(17.02.2011 15:47 )mikeee schrieb:  Ich dachte das so: ...

Zitat:Gibt es keine Möglichkeit eine statische Referenz zu verwenden? Geht wohl nicht weil das einzelne Programme sind, die halt nicht gelinkt sondern nur dynamisch zu Laufzeit gekoppelt werden und dann weiss ja vorher keiner wo das im Speicher liegen wird... sehe ich das richtig?

... jetzt wird's kompliziert ...

Eine Referenz auf ein Anzeige/Bedien-Cluster kann als statisch angesehen werden. Statisch heißt in diesem Falle, dass die "Referenz" zur Entwicklungszeit erstellt wird. Siehe Kontextmenü des Clusters Erstelle->Referenz. Das mit der Referenz auf einen Cluster hat aber gar nichts damit zu tun, ob das SubVI direkt (plaziert auf BD) oder indirekt (per VI-Server) aufgerufen wird. Bei beiden SubVI-Aufruf-Verfahren weiß man zur Entwicklungszeit nicht, wo die Daten im Speicher liegen. Dass (und wie) die tatsächliche Speicheradresse bzw. die Referenz darauf erst zur Laufzeit generiert wird, obliegt der Magie des Compilers. Statisch heißt die Referenz deswegen, weil sie während der gesamten Programmlaufzeit konstant ist.

Erstellen kann man die Referenz nur in dem SubVI, in dem der Cluster liegt. Daher muss dieses SubVI die Referenz explizit der FGV übergeben.

[*NachDenk*]
Theoretisch könnte es möglich sein, die Referenz auf ein Anzeige/Bedien-Element auch per VI-Server mit einem entsprechenden Property zu holen. Das könnte dann die FGV selbständig machen - das würde ich dann als dynamisch auffassen. Allerdings: Woher weis die FGV, wie das SubVI heißt, aus dem der Cluser ... Aber: Warum einfach, wenn's auch kompliziert geht.
[/*NachDenk*]

Eine Referenz ist alleine deswegen nötig, weil sich der Cluster, der bearbeitet werden soll, in einem anderen SubVI befindet als der Algorithmus, der den Cluster manipulieren soll. Der Algorithmus kann hier nur über eine Referenz auf den Cluster direkt zugreifen (indirekt wäre z.B. über Queue etc).

Zitat:INI-Files sind aufwändiger als was?

... als XML.