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.
Related
I have a project consisting of multiple nested functions.
For debugging purpose I want to save all internal variables in one way or another, in order to display figures, replay parts of code etc...
I also want to keep this as transparent as possible regarding calculation time.
My first thought was to create a global variable, and store programmatically at the end of each function the inputs and outputs inside the variable as a structure :
globalVariable.nameOfParentfunction_NameOfFunction.nameInput1 = valueInput1;
globalVariable.nameOfParentfunction_NameOfFunction.nameInput2 = valueInput2;
...
globalVariable.nameOfParentfunction_NameOfFunction.nameOutput1 = valueOutput1;
...
Is it possible to use some kind of reflection to get the name and value of inputs/outputs without necessarily parse the file where the function is written?
I found a good but maybe outdated topic about parsing
How do I collect internal signals?
The simple solution is to use save, which will save all variables in the current workspace (the function’s context) to file.
If you want to keep the values in memory, not in a file, you can use names = who to get a list of all variables defined in the current workspace, then use val = eval(names{i}) to get the value of the variable called name{i}.
I would recommend putting all of that in a separate function, which you can call from any other function to store its variables, to avoid repeating code. This function would use evalin('caller',…) to get names and values of variables in the workspace of the calling function.
Note that using eval or evalin prevents MATLAB from optimizing code using its JIT. They also are dangerous to use, since they can execute arbitrary code, however in this case you control what is being executed so that is no a concern.
I am using functions from a MATLAB package ("EEGLAB"). One of the functions I'm using ("pop_selectcomp") creates a GUI. However, when I try to interact with the GUI, an error results: an expected variable (In this case "EEG", a data structure) is not defined. That's odd, because pop_selectcomp has EEG as an input. I discovered that declaring global EEG anywhere in the function stack above my call to pop_selectcomp makes EEG available to it again. This is the structure of my function stack.
Main Script
data import function loads variable "EEG"
function to process data
function call to pop_selectcomp
So declaring EEG as a global in the main script or the data processing function fixes the problem.
My interpretation is that when pop_selectcomp creates its GUI window, it's being created outside of my function stack in the main workspace or something like that. So, the EEG variable is only available to it if it's been declared global above the function call. I'm not very familiar with Matlab figures and GUIs, but I guess that normally pop_selectcomps doesn't have this problem because it's not called as a sub-function.
Is there any better way to make this work? Can I somehow point pop_selectcomps' GUI at the correct sub-workspace where it will find the variables it needs? I can modify pop_selectcomps if I have to, although that would be messier. The function can be found here:
https://sccn.ucsd.edu/svn/software/eeglab/functions/popfunc/pop_selectcomps.m
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 am now using Matlab GUI and have problem during accessing return values from a function which is set by set().
Situation:
I set the windowMotionFcn as below:
set(gcf,'WindowButtonMotionFcn',#test);
Function 'test' can return 2 variables (named as var1 and var2).But I dont know how to store them...
I have searched in the Internet and could not find any way.
How should I write?
Thank you for your help and kind attention.
I think that what you want to do is to return a value from the callback function. And regarding returning a value from a callback I am not sure that is possible. I found an old article from matlab newsreader. I think your problem could be similar.
However, if you have a matlab GUIDE GUI, there is a way to return a value from a gui. It is described in a matlab tutorial in matlab central: advanced-getting-an-output-from-a-guide-gui. What you must do is to modify your CloseRequestFcn and your OutputFcn.
Another way, which should work is using global variables. A global varable exist in the global workspace. That means that it can be seen and accessed by every function in matlab. Global variables are in most cases not recommended, but if no other solution exists they may be necessary. Just make sure to document them, so that the next person to take over your code knows that they are there. Also make sure to select a good name for the globals, like gblMyVar so there can be no confusion that the variable is global.
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.