Wenn dein Problem oder deine Frage geklärt worden ist, markiere den Beitrag als "Lösung",
indem du auf den "Lösung" Button rechts unter dem entsprechenden Beitrag klickst. Vielen Dank!
nach mehrmonatiger Plagerei ist mein neues (und erstes größeres) Projekt nun im Großen und Ganzen fertig. Was nun noch ansteht ist es eine ansprechende und passende Benutzeroberfläche zu gestalten.
Zur Zeit arbeite ich mit einer Oberfläche, die zwar funktioniert, aber mehr oder weniger nur für mich erklärend ist. Im Besonderen geht es mir darum nun eine ansprechende Speicher und Lademöglichkeit zu gestalten.
Da ich weiß, dass viele von euch hier ständig große Projekte entwerfen und sicher Methode entwickelt haben um solche Probleme anzugehen, würde ich mich über ein paar Anregungen, wie ich das am Besten angehe freuen.
Folgende Problemstellung also:
- 1 Interface mit (Hausnummer) 50+ Controls (5-10 TypDef Cluster, die am Schluß in einem Cluster aus Cluster ans Programm gehen)
- Speichern/Laden der Einstellungen über XML Files
- Teilspeicherung (also die Möglichkeit nur bestimmte (definierte) Teile der Einstellungen in Dateien zu speichern)
- Der User soll die Möglichkeit haben die geladenen Einstellungen zu sehen und zu ändern, bevor er akzeptiert.
- Es kommen sicher mit der Zeit Controls hinzu, das ganze soll also möglichst einfach zu erweitern sein
Zur Zeit löse ich das Ganze über ein EventCase, dass Laden, Speichern abfängt und schreibe dann in einer State-Machine (um Platz im BD zu sparen), die die einzelnen Cluster abarbeitet, die Daten in die XML File, bzw. über lokale Variablen in die Controls. Das funktioniert soweit ganz gut, jedoch frage ich mich, ob es hier elegantere Möglichkeiten gibt?
Grüße
Kvasir
A few weeks of developement and testing can save a WHOLE afternoon in the library!
' schrieb:Zur Zeit löse ich das Ganze über ein EventCase, dass Laden, Speichern abfängt und schreibe dann in einer State-Machine (um Platz im BD zu sparen), die die einzelnen Cluster abarbeitet, die Daten in die XML File, bzw. über lokale Variablen in die Controls. Das funktioniert soweit ganz gut, jedoch frage ich mich, ob es hier elegantere Möglichkeiten gibt?
Hast du dir schon mal die "OpenG Variant Configuration VI" angschaut ?
Die haben VI zum lesen/schreiben von Cluster oder Controls auf dem FP (via VI-Ref), aber in eine INI Datei mit den Config.vi.
Mit XML bist du sicher moderner, da das inlv86eh verbessert wird/wurde. (eigene Schema zum validieren).
Ev. wäre es eine gute Idee, das Konzept der OpenG VI auf deine XML zu portieren.
Gruss
RoLe
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
25.07.2008, 10:01 (Dieser Beitrag wurde zuletzt bearbeitet: 23.06.2009 10:37 von eg.)
Es entpricht zwar nicht genau Deinen Vorgaben, aber ich will Dich auf jeden Fall auf ein Beispiel-VI hingewiesen haben, dass ich auch schon mal gepostet hatte und von dem ich jetzt nicht mehr weiß, wo es eigentlich her ist.
Es werden damit auf Kopfdruck die Werte aller Bedienelement in einer binären Datei gespeichert, auf geradezu sensationell einfache Weise, und ebenso wieder geladen. Der Witz dabei ist, daß diese Bedeinelemente in ihrer Datenstrukur völlig unterscheidlich sein können und im einzelnen gar nicht benannt zu werden brauchen - eben einfach alle.
Und ich traue Dir zu, das als interessanten Ansatz zu verwenden, um daraus genau das zu machen was Deinen Vorstellungen entpricht.
Das VI war eine Uraltversion, habe es lauffähig fürlv85gemacht.
Developer Suite Core -> LabVIEW 2015 Prof.
2006
EN
71083
Deutschland
User Interface
Je nach Anzahl der abzuspeichernden Einstellungen könntest Du sogar eine kleine Datenbank verwenden.
Wenn es sich vom Umfang aber in Grenzen hält, dann finde ich Deine Idee auch nicht schlecht.
Gruß Markus
-------------------------------------------------------------------------- Bitte stellt mir keine Fragen über PM, dafür ist das Forum da - andere haben vielleicht auch Interesse an der Antwort !!
--------------------------------------------------------------------------
25.07.2008, 10:14 (Dieser Beitrag wurde zuletzt bearbeitet: 25.07.2008 10:16 von eg.)
@Lucki, binär abspeichern ist genauso einfach wie XML, hat aber den Nachteil, dass man die Datei mit Einstellungen mit einem Editor nicht editieren kann. XML ist dagegen ein verständlicher ASCII Text, den man händisch ändern kann.
' schrieb:@Lucki, binär abspeichern ist genauso einfach wie XML, hat aber den Nachteil, dass man die Datei mit Einstellungen mit einem Editor nicht editieren kann. XML ist dagegen ein verständlicher ASCII Text, den man händisch ändern kann.
Das war mir schon klar, daß das gepostete VI nicht in allen Punkten den Vorgaben von Kvasir entspricht, u.a. in der Speicherungsart.
Damit will ich mich jetzt nicht beschäftigen. Meine Anfangsvermutung aber ist, daß sich am geposteten VI die Speicherung mit vergleichsweise geringfügigen Änderungen von binär in HTML ändern läßt. Vielleicht bist Du hier eingearbeitet und kannst das bestätigen oder verneinen.
' schrieb:Das war mir schon klar, daß das gepostete VI nicht in allen Punkten den Vorgaben von Kvasir entspricht, u.a. in der Speicherungsart.
Damit will ich mich jetzt nicht beschäftigen. Meine Anfangsvermutung aber ist, daß sich am geposteten VI die Speicherung mit vergleichsweise geringfügigen Änderungen von binär in HTML ändern läßt. Vielleicht bist Du hier eingearbeitet und kannst das bestätigen oder verneinen.
Finde ich auch, das wichtige ist ja hier, die Methode Control Value:Get All... in welchem Format danach gespeichert wird ist was anderes.
Teilweise kann es auch von Vorteil sein, das die DAtei/Einstellungen nicht von jedem Editor verändert werden können.
@Kvasir: Mit dieser Methode machen es auch die OpenG.vi's, wie in Post#2
.·´¯)--> Leben ist das, was dir passiert, wenn du eifrig dabei bist andere Pläne zu machen <--(¯`·.
Ich werd mir jetzt mal auf jeden Fall die VIs von OpenG ansehen. Wenn ich das richtig verstanden habe machen die ja im Prinzip auch das, was das Beispiel von Lucki tut, nämlich die Controls vom FP auszulesen. Klingt auf jeden Fall mal nicht schlecht.
Das umschreiben auf XML dürfte an sich kein Problem sein.
Ich meld mich dann wieder, wenn ich etwas schlauer geworden bin
A few weeks of developement and testing can save a WHOLE afternoon in the library!