Suppose that I have a button in a window that when I click on it a new window will appear. I call this window (with the name of My_New_Window) with this syntax:
My_New_Window();
I want to insert some values to this new window from main window. I know that I can use setappdata or getappdata for this purpose but Is there another way to this? For example like this syntax:
My_New_Window(Values);
Another question. When we use setappdata or getappdata, where MATLAB stores this data? In the RAM or Hard drive?
Yes, you can use My_New_Window(Values); For example, in GUIDE, whatever parameters you pass to your GUI, you can handle in the OpeningFcn using its varargin input. Simply assign varargin to your handles structure and use guidata(hObject, handles);
Regarding setappdata - according to this book the data is stored inside an "object". Since objects reside in memory, it is safe to assume that it is indeed kept in RAM.
You can store data in the GUI UserData property:
set(handletoFigure,'UserData',Values);
when you open the other GUI you retrieve the info:
Values = get(handletoFigure,'UserData);
Is there a reason why you don't want to use setappdata/getappdata?
As for your 2nd question I don't know sorry. I guess it's the RAM though
Related
I'm working on a fairly complex (for me) GUI in Matlab, made programmatically without GUIDE.
The different but similar ways to organize GUI objects confuse me. Please tell me where my understanding is incorrect, and if they're actually different at all:
What is the functional difference between the two following handles structures:
1) A handles populated by the... handles?... of GUI objects created explicitly with a handles. prefix. The guidata function is used in Callback functions to grab an up-to-date copy of handles and then save it.
handles.button = uicontrol(...);
guidata(handles.fig,handles);
appears in handles as button.
2) A handles populated by the 'Tag' fields of GUI objects in a figure fig. This structure is created, after(?) drawing all of your GUI objects, using guihandles.
button = uicontrol(...'Parent',fig,'Tag','push'...);
handles = guihandles(fig);
appears in handles as push.
The guidata function doesn't seem to save to the handles struct made by guihandles. Is it necessary to instead use handles = guihandles(fig) at the end of every Callback?
Or am I thinking about the second type of structure wrong, and is bothering with the handles. prefix unnecessary altogether? Because creating a new GUI object and immediately entering just
guihandles
into the console shows the new GUI object listed with my old GUI objects. But I see this new object is stored openly in my Workspace, and is not under handles until I use
handles = guihandles;
again.
I apologize if it takes a re-read or two of all of the above to get what I'm asking.
There is no difference between the two handles structures that you mention. Both structures should be the same.
It is necessary to use handles=guihandles(fig); instead of guihandles by itself because you need to tell Matlab where to store the results of the guihandles function. If you do not give it a variable to store the results to on the left hand side of the equals sign, it will store your resulting structure in the ans variable.
It's not necessary to create the handles structure at the end of each callback. You should be able to use guihandles to create your handles structure only as you need it.
I am new to using GUIDE and using GUIs in Matlab.
I am running a script in Matlab that will accept initial inputs from the user and then proceed to open up a GUI (created with GUIDE) which will accept further inputs from the user. However, I cannot figure out a way to transfer variables and data between my script and my GUI. I am aware that script variables/data and GUI variables/data are saved in different workspaces; I just need some simple way to communicate between the two.
Thanks.
A simple way would be to use setappdata and getappdata in order to store your variables/input/whatever so that it's accessible from wherever you want.
Let's say you delcare some variable in your script that you want to retrieve in your GUI:
A = rand(100,100);
Then using setappdata like the following:
setappdata(0,'VariableName',A);
will store the data in the root directory (the 0 as the 1st input), meaning that using getappdata like this in the GUI:
A_in_GUI = getappdata(0,'VariableName');
will allow you to retrieve the value from your GUI, or from any other script as long as you use the correct variable names of course. Notice that you can use a handle to some figure/GUI where you could save your data, like this;
setappdata(handles.Something,'VariableName','A);
but if you close the figure, for instance, you might not be able to retrieve your variable.
As Tyler pointed out, a nice way to share data between different callbacks inside your GUI is to use its handles structure. More info here.
Final Note:
If you don't want to spend your time sharing many variables between scripts and GUIs, you can store all of your variables in a single large structure and use setappdata/getappdata only on this structure, which will keep all your variables updated.
For instance, you can write something like this in the script:
Variables_Structure.MyFavoriteNumber = pi;
Variables_Structure.MyFavoriteSport = 'ice hockey';
setappdata(0,'MyVariables',Variables_Structure);
and then getappdata in the GUI in which you want to use the variables:
Variables_in_GUI = getappdata(0,'MyVariables');
I have designed a MATLAB GUI by GUIDE for image analysis. I need to share data between functions so I used the guidata function and stored it in the handles-object as it is documented (http://www.mathworks.de/de/help/matlab/ref/guidata.html).
For the auto generated callback functions (which receive handles automatically) this works well, however I also want to modify the data in self-written functions and self-written callback functions (like click on image events). I tried manually passing the handles object which gives me read access to the data but no way to store it. I tried passing the object handle too, to use guidata(hObject, handles) but the object handle does not work then.
In short: I need a way to read&write data from all functions in the file. I'm looking for a more elegant way than making everything global. That would be my last resort.
Do you have any ideas?
In GUIs, you can use the function setappdata / getappdata in order to store and share data structure between functions (link to docs).
You can use the figure as the handle. For example:
appData = struct;
appData.image = someImage;
appData.title = "someTitle";
setappdata(handles.figure1,'data',appData);
Later, you pass handles to your functions, and you can retrieve your data:
function showTitle(handles)
appData = getappdata(handles.figure1,'data');
title = appData.title;
newTitle = "someNewTitle";
appData.title = newTitle;
setappdata(handles.figure1,'data',appData);
EDIT: Just found this link, which specifies multiple strategies to share data among callbacks.
Thank you a lot! I found the error while trying to produce a reproducebable example. In my case I was using the image handle instead of the figure handle in one function because it was an image click callback and inside that function the image was redrawn so the handle wasn't valid any more.
I use gcf now to obtain the figure handle and it works fine.
I have a MATLAB GUI that loads to aid in visually pre-processing data. Essentially it prompts the user to adjust the data range, reduce number of data points, etc... all while providing an updated graph. Upon completion of this work, I want to be able to close out the GUI and pass variables from the GUI to another MATLAB function that does the data analysis. I have found lots of information on how to pass information from a function TO and GUI, but not the other way around.
Any help would be greatly appreciated.
Global variables can cause hard to find bugs. The best solution for your problem (where you want to pass the data directly to another function on close) might be to call the analysis function from the Figure Close Request Function. When the figure your GUI is running in is told to close, it will run the code in this function, which can call your analysis function and have access to the GUI's data.
Matlab GUIs are functions: the code exists in a .m file just like other functions. Like regular functions, they can have return values. You can get as fancy as you want messing with the varargout system, or you can simply return a value, structure, or cell array containing whatever you want. Open up the m-file and edit it to return what you want it to.
Note: If you require special processing when the figure is being closed to generate the appropriate return value, you can reimplement the closeRequestFcn as you see fit.
The easy way: you declare as global variable, where variable stores the data that you want to carry from the GUI to the main MATLAB workspace. Then, you also declare the same global variable on the command window. Hereinafter, variable to be accesible from both scopes, the GUI and the main workspace.
You could also use save or any other alternatives as csvwrite or dlmwrite to store the data into a file, but this doesn't seem to be your case.
I have an object-oriented MATLAB app that needs a GUI, and I'd like to use GUIDE for the layout (at least). I've tried the manual way, and doing the control positioning is just too painful.
I've noticed that GUIDE is very much procedurally-oriented; it generates M-files that assume they are run from the path and aren't associated with any classes or objects.
Has anyone had experience trying to use GUIDE in an object-oriented way? If it's straightforward, I'd like to do automatic code generation as well, but I'm willing to let GUIDE just generate the .fig file and write the code myself.
When you create a gui with guide, for every button/textbox/graph etc. you put on the pane, it automatically generates the shells for the necessary callbacks, so all you have to do is fill in the code. If you change the name of the widgets (their "tags") or add or delete them, it updates your m-file for you, which is handy.
You can associate your gui with objects; the autogenerated m-file has a function outline that looks like this
function YourGUIName_OpeningFcn(hObject, eventdata, handles, varargin)
you can require that someone pass your gui an object or objects through the varargin. The canonical matlab way to do this is to pass parameter name/value pairs, so the call from the command line would look like
YourGuiName('importantobject', object1);
but you could also (especially if there is just one unique argument) assume varargin{1} is a specific parameter, varargin{2} is a second, and so on
In this case, the call from the command line would be
YourGuiName(object1);
In your openingfcn, you would then add a line like
if (length(varargin) < 1) || ~isa(varargin{1}, 'importantObjectType')
error ('you must pass an importantobject to YourGuiName, see help');
end
myimportantobject = varargin{1}
You now have a choice to make. The canonically correct way to store data in your gui is to put it in the handles structure and then store it with guidata, as in
handles.myobject = varargin{1};
guidata(hObject, handles); %this is just boilerplate
The boilerplate is necessary because, despite its name, handles does not subclass Handle, and is passed by value, not reference. the guidata command sticks handles somewhere associated with the gui figure so you can get it in subsequent callbacks.
The problem with this approach is that when you put a large object in handles, it makes the guidata command take forever. This is true even though MATLAB is not supposed to copy data when passing by value unless absolutely necessary, and it is even true if your object is a Handle, which takes like 4 bytes to pass back and forth. Don't ask me why, but I suspect it has something to do with memory management & garbage collection.
If your gui is taking a while to execute commands, and you use profile and see it hanging on the guidata command, you should just declare your object to be a global and deal with it that way
global YOURGUI_object; %it's not my fault; blame MATLAB
YOURGUI_object = varargin{1};
Then you can just have all your callbacks execute whatever method of YOURGUI_object they need.
Good luck.