|
|
|
guidata, userdata, appdata - wann was anwenden? |
|
| Flutsch |
Forum-Anfänger
|
 |
Beiträge: 19
|
|
|
|
Anmeldedatum: 20.03.10
|
|
|
|
Wohnort: Rostock
|
|
|
|
Version: ---
|
|
|
|
 |
|
Verfasst am: 17.02.2012, 19:50
Titel: guidata, userdata, appdata - wann was anwenden?
|
 |
| |
 |
 |
Moin,
ich schreibe gerade eine kleine GUI, in der unter anderem dateien eingelesen werden. Hierzu kann man den Ordner in dem die Dateien sich befinden explizit angeben. Dieser Pfad wird nun von einem anderen Callback benötigt. Hierzu bin ich auf 3 (eigtl. 4) Möglichkeiten gestoßen das zu bewerkstelligen: guidata, appdata oder userdata verwenden... In der Matlab Hilfe hab ich mir auch die entsprechenden Abschnitte durchgelesen und frage mich nun ob ich iwas falsch verstanden habe, bzw ob es irgendwelche "Richtlinien" gibt, wann man welche der 3 Arten Werte zu speichern benutzen sollte?
Von meinem Verständnis her ähneln sich die 3 fkt. nämlich stark... im groben hab ich's so verstanden:
guidata:
->die qual der Wahl wenn man der handles structure ein neues Feld zuweisen möchte
userdata:
-> jedes Objekt besitzt eine "userdata" property, in der man logischerweise daten seiner wahl speichern kann
application data:
-> ähnlich der userdata, allerdings legt man für das Objekt der Wahl eine neue property an, welche man logischerweise explizit auch benennen muss
->vorteil ist halt, dass man beliebig viele verschiedene zusätzliche properties hinzufügen kann
Für meinen Zweck einfach ein paar Daten zu speichern auf die mehrere Callbacks zugreifen können, wäre ja guidata total ausreichend....allerdings find ich es eher unlogisch daten in einer struct zu speichern die den Namen "handles" trägt, obowhl die Daten rein gar nix mit handles zu tun haben...
Nutze ich hingegen userdata, könnte ich die Daten a) in den Objekten speichern, wo sie auch erstellt werden oder b) im Vater der ganzen Objekte nähmlich in der GUI-Figure selber. Hier würde ich b) favorisieren, da ich mich erinnere mal gelernt zu haben Probleme dort zu lösen wo sie entstehen, sprich ich will in jedem Callback auf eine bestimmte Variable zugreifen? Dann sollte ich wohl in der GUI-Figure auch ein endsprechendes Feld anlegen...
Nächste Möglichkeit wäre natürlich noch application data zu verwenden, allerdings ist das ja fast identisch zur Überlegung über die Benutzung von userdata, nur das hier halt extra neue Properties angelegt werden....
Also nochmal zur Grundfrage zurück: Hab ich iwo nen Denkfehler, isses einfach Lachs was man macht oder gibt's einfach Richtlinien bzw. vorgehensweisen die eher guten/schlechtem stil endsprechen?
Wer sich bis hier alles durchgelesen hat, dem sei schonmal gedankt  ...hoffe ich konnte mein Problem verständlich machen...
PS:Wenn ich keine groben Verständnisprobleme habe, sollte es meines erachtens nach zumindest rein funktional betrachtet egal sein, allerdings möchte ich halt vermeiden mir bei kleinen GUI's schlechten stil anzueignen, welcher mir später bei evtl. größeren/komplexeren GUI's auf die Füße fällt...
Nachtrag: Favorisieren würde ich momentan die Variante mit user data. ganz einfach weil es mir gerade am plausibelsten vorkommt dor tne struct anzulegen und für jeden Wert der für mehrere Callbacks zur Verfügung stehen muss einen endsprechenden Eintrag in der Struct anzulegen...
|
|
|
|
|
|
| outsider |
Forum-Meister
|
|
Beiträge: 806
|
|
|
|
Anmeldedatum: 03.09.07
|
|
|
|
Wohnort: München
|
|
|
|
Version: R2012b
|
|
|
|
|
|
|
Verfasst am: 17.02.2012, 20:20
Titel:
|
|
| |
|
|
Moin,
Deine Überlegungen sind absolut richtig und logisch! Und auch die Fragen sind nicht aus der Luft gegriffen.
Selbstverständlich kannst Du die Daten überall speichern wo Du sie haben willst. Am einfachsten ist es (und allein schon weil Du mit dem GUIDE arbeitest), wenn Du die Daten im handles-Struct speicherst. Einfach - weil der handles-Struct in jedem Callback automatisch zur Verfügung steht und dieser Weg auch von MATLAB empfohlen (sprich: Richtlinie) wird. Aus meiner Sicht sollte jeder der mit GUIDE seine GUI's erzeugt die Daten auch im Handles-Struct speichern und die "Kreativität" an der Stelle beiseite lassen. 
UserData würde ich local für temp- und unwichtige Daten benutzen. Bzw. die speziell für den UI-Object gebraucht werden.
ApplicationData benutze ich wenn Daten zwischen den mehreren GUI's ausgetauscht werden sollen.
Es gibt noch eine Art GUI's aufzubauen ohne dabei den handles-struct, userdata oder application data zu verwenden. Und zwar wenn Du mit Nested-Functions arbeitest. Dann sind quasi alle Daten innerhalb der Funktion aus jedem Callback sichtbar. Eignet sich eher für kleinere und überschaubare GUI's.
Gruß
|
|
|
|
| Flutsch |
Themenstarter
Forum-Anfänger
|
|
Beiträge: 19
|
|
|
|
Anmeldedatum: 20.03.10
|
|
|
|
Wohnort: Rostock
|
|
|
|
Version: ---
|
|
|
|
|
|
|
Verfasst am: 17.02.2012, 20:32
Titel:
|
|
erstmal, danke für die schnelle und kompetente antwort. Also doch die handles-struct, hatte sowas schon fast vermutet weil ich es relativ oft gesehen hab...allerdings find ich's dann immernoch gewöhnungsbedürftig die struct "handles" zu nennen...
hab gerad gesehen, dass bei Benutzung des GUIDES in den KOmmentaren zu jedem Callback folgende Zeile entdeckt:
"% handles structure with handles and user data (see GUIDATA)"
damit wird's dann natürlich einleuchtender...tja, wer lesen kann ich klar im vorteil 
|
|
|
|
|
|
|
Einstellungen und Berechtigungen
|
|
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum posten
Du kannst Dateien in diesem Forum herunterladen
|
|
Impressum
| Nutzungsbedingungen
| Datenschutz
| FAQ
|  RSS
Hosted by:
Copyright © 2007 - 2025
goMatlab.de | Dies ist keine offizielle Website der Firma The Mathworks
MATLAB, Simulink, Stateflow, Handle Graphics, Real-Time Workshop, SimBiology, SimHydraulics, SimEvents, and xPC TargetBox are registered trademarks and The MathWorks, the L-shaped membrane logo, and Embedded MATLAB are trademarks of The MathWorks, Inc.
|
|
