How to use varargout in a GUI

Hi,

There is clearly something I don't understand about getting data from a gui into my main code. For the purposes of an example, I created a gui using GUIDE that contained a single edit box that I left exactly as it was created. In the automatically generated code are lines in OpeningFcn that define handles.output and update guidata:

function dummy_OpeningFcn(hObject, eventdata, handles, varargin)

% Choose default command line output for dummy
handles.output = hObject;

% Update handles structure
guidata(hObject, handles);

Then, in the OutputFcn, varargout{1} is set equal to handles.output:

function varargout = dummy_OutputFcn(hObject, eventdata, handles)

% Get default command line output from handles structure
varargout{1} = handles.output;

When I run the gui I don't see any variables in the main workspace. What is varargout for if not to pass data to the main workspace? Is there something missing from the automatically generated code that I need to insert so I can access handles.output in the main workspace?

Thanks,

Simon.

[Adam]

You need to make your GUI modal by using the uiwait command in the OpeningFcn and uiresume at an appropriate moment.

Otherwise the OutputFcn is called as soon as the GUI is rendered and thus is of very little use. There are other ways to get data out of a UI too, especially if you want the UI to remain open, and work in another UI at the same time, but if you just want the user to open the GUI, be forced to interact with it and then close it before anything else becomes usable again then uiwait will do that for you.

[dpb]

There has to be an assignment to something for the result of dummy_OutputFcn to go to.

[Simon Aldworth]

Hi Adam. Yes, I understand that, but that's not what I'm asking. Once OutputFcn has run the value of varargout{1} is equal to handles.output. Handles.output is a reference to the figure and all its properties. The question is how to make varargout and, consequently, the figure properties accessible to the main workspace?

Hi dpb. Care to expand?

Thanks,

Simon.

[Adam]

Handles.output is just whatever you have set it to be as a static value. In your case you set it to hObject at the start of your GUI creation. This would just be a regular figure handle containing nothing specific to the GUI that sits inside it.

myGUIOutput = dummy( )

would give you that output, whatever it has in it, though, assuming your GUI is called 'dummy'

[Simon Aldworth]

Adam, I still don't understand why I can't see varargout in the main workspace, even if it doesn't contain anything useful yet.

[OCDER]

varargout is a special variable for matlab function. Used for variable output. It's a cell array. You don't normally output varargout as a variable in the main workspace.

https://www.mathworks.com/help/matlab/ref/varargout.html

[Walter Roberson]

varargout is a special keyword, not a normal variable. It allows you to treat the entire list of output variables as if it were a cell array. In itself it does not cause assignments to variables outside the function. You need to have the calling routine assign the output of the gui to a variable.

[Walter Roberson]

To emphasize:

When you have a function

function [variable1, variable2, variable3, ...] = FunctionName(input1, input2, ...)

then when you run the function with appropriate inputs, MATLAB does not assign to variable1, variable2, variable3, ... in the workspace of the caller. Those variable names are completely local to the inside of the function, and stand in for the output names that the user provided when calling the function, such as

[x, y] = FunctionName(.....)     %invoking the function

Here, whatever was assigned to variable1 inside the function will be assigned to x in the workspace where the function was invoked, and whatever was assigned to variable2 inside the function will be assigned to y in the workspace where the function was invoked. Whatever was assigned to variable3 inside the function will be ignored by the calling routine because there are no output slots to receive the value.

The names used inside the function have no connection to any variables with the same name in the calling routine. The connection is purely positional: the first variable in the output list in the function is transferred to the first output variable listed in the calling routine.

[dpb]

Simon, see the doc Example 1 for assignin

In general, don't recommend it as a coding technique and it's not clear what you intend by assigning to the workspace, but that's the "how" to get something to show up there from wherever it is that it is...as others said, varargout is not actually a variable and I've not tried to write a test case to see if will work directly as argument or whether you'll have to dereference its content.

[Simon Aldworth]

Thanks all.

dpb: you say you don't recommend it as a coding technique. What do you recommend? I had assumed that one would have a main code file that would call a gui to ask the user for data. This data would then be passed back to the main code for use and manipulation. Are you saying that all the code can be inside the gui code and that the main code is literally only for calling the gui?

My gui asks for 22 bits of information from the user. At the moment I have used the handles struct to store it, by adding fields:

% Set handles fields with initial values from UIcontrols
handles.mass = str2double(get(handles.editMassNom,'String'));
handles.pinertia = str2double(get(handles.editPInertiaNom,'String'));
handles.wb = str2double(get(handles.editWBNom,'String'));
etc, etc.

I then need to manipulate this data and, as said, have assumed that this is best done in the main code and workspace. So, following some initial processing of the data that isn't important here, I use assignin to pass all the information to the main workspace.

Is this appropriate? Or is there a neat way of getting the 22 bits of information stored within handles direct to the main workspace?

Regards,

Simon.

[Adam]

Generally you would call your main code from the GUI. It should be self-contained. Obviously it can (and should) call functions external to the GUI itself, but it shouldn't be bouncing back to the main workspace.

Usually a GUI would have some button or other that triggers the calculation. Basically the same as you presumably have to finish with the GUI and dump the parameters back to the workspace.

[Stephen23]

@Simon Aldworth: avoid using assignin, or any other method that magically makes data appear or disappear from another workspace. Read this to know some of the reasons why:

https://www.mathworks.com/matlabcentral/answers/304528-tutorial-why-variables-should-not-be-named-dynamically-eval

Beginners often seem to love making data appear and disappear because they like to see all of their data in the base workspace. Experienced users handle all of the data within the GUI itself, which also leads to simpler, more robust, more efficient, less buggy code.

If you really want to return values to the base workspace then either use nested functions and waitfor (if you are sensibly writing your own GUI), or use the OutputFCN (if you are unfortunately using GUIDE).

[Walter Roberson]

http://matlab.wikia.com/wiki/FAQ#How_can_I_share_data_between_callback_functions_in_my_GUI.28s.29.3F