How to communicate two matlab gui?

Hello, I am creating a maingui and subgui. There is push button in the maingui after clicking it I want to open subgui and then in subgui there is edittext box in which I want to put value after putting the value I want to close that window and want to use that editbox value in the main gui and want to display the calculation under pushbutton of maingui into another textbox. Can anyone suggest the solution using example? Thanks..!!

[Stephen23]

The MATLAB documentation clearly explains how to pass data between callbacks, and it has examples:

https://www.mathworks.com/help/matlab/creating_guis/share-data-among-callbacks.html

and it also has clear explanations of how to pass data between workspaces:

https://www.mathworks.com/help/matlab/matlab_prog/share-data-between-workspaces.html

My favorite is to use nested functions: simple, intuitive, fast, efficient.

[Adam]

Here was a similar discussion in the past where I detailed my preferred solution for GUI communication

https://uk.mathworks.com/matlabcentral/answers/315054-how-to-transfer-data-from-one-gui-to-a-uitable-of-another-gui

For this case though, if it is as simple as you say then the simple methods used in the documentation work fine, most particularly uiwait with uiresume and a modal second GUI so that you have to respond in that GUI, then it will close and only then can you do anything back in the main GUI again.

My solution is for the more general approach of two GUIs communicating where you do not necessarily wish to have to do everything in the 2nd GUI and close it down before you can do anything in the main GUI.

[VISHWAS CHAVAN]

Hello, I read out https://www.mathworks.com/help/matlab/creating_guis/share-data-among-callbacks.html from this but I am not getting it clearly that's why I ask to suggest with example.If you could be able to explain me with example then please..

[Adam]

That page is full of examples. What are you expecting us to do? Spend our whole morning copying it out from there to here?

[VISHWAS CHAVAN]

Thanks....!!! I am using setappdata and getappdata command to solve it

Answer 1

[Jan]

function MainGUI
handles.GuiH = figure('Name', 'Main', 'Tag', 'myMainGUI');
uicontrol('Style', 'PushButton', 'Position', [10, 10, 100, 25], ...
          'String', 'Start SubGUI', 'Callback', @StartSubGUI);
handles.TextH = uicontrol('Style', 'Text', 'Position', [10, 50, 100, 25]);
guidata(handles.GuiH, handles);  % Store handles struct in figure
end

function StartSubGUI(ButtonH, EventData)
handles = guidata(ButtonH);  % Obtain handles struct store in figure

handles2.SubGuiH   = figure('Name', 'SubGUI');
handles2.MainGuiH  = handles.GuiH;
handles2.MainTextH = handles.TextH;
handles2.TextH     = uicontrol('Style', 'Text', 'Position', [10, 50, 100, 25], ...
                          'Callback', @SubTextCB);
guidata(handles2.SugGuiH, handles2);
end

function SubTextH(TextH, EventData)
handles2 = guidata(TextH);
% Copy the text to the main gui:
set(handels2.MainTextH, 'String', get(TextH, 'String'));

% Store the string in the main gui's application data:
handles = guidata(handles2.MainGuiH);
handles.TextFromSub = get(TextH, 'String');
guidata(handles2.MainGuiH, handles);
end

Now the text typed in the sub GUI is available in the main GUI also, either in the text field or in the handles struct. Choose the solution you prefer.

Alternatively you can use the 'UserData' of the main figure, or the set/getappdata commands. The general idea remains: Provide the handle of the main GUI to the callbacks of the sub GUI.

If you have created the GUIs by GUIDE, forwarding the handles is much harder. Then you can search the handles on the fly:

function SubTextH(TextH, EventData)
MainGuiH = findobj(allchild(groot), 'flat', 'Tag', 'myMainGUI');
if isempty(MainGuiH)
  error('Main GUI is not found.');
end
handles = guidata(MainGuiH);
... same as above

[Adam]

You can pass the handle of the main GUI into the sub-GUI if you want when created using GUIDE. Then you can access its handles. It's ugly and bad design, but it works and anything that is accessing GUI handles of a different GUI is always going to be ugly from a design perspective anyway!

You never want to have to use findobj in a callback when you can avoid it though.

[Jan]

@Adam: I do not work with GUIDE because of the limited compatibility between Matlab versions. Could you post some code to show, how to open a figure created by GUIDE providing an input argument?

It would be nicer to have a window manager, which allows to pass messages between the GUIs. But even then the sub-GUI must know how to address the main-GUI. What would be a not ugly way?

[Adam]

function StartSubGUI(ButtonH, EventData)
handles = guidata(ButtonH);
SubGUI( handles.figure1 );

would call a GUIDE GUI called SubGUI and pass in the main GUI figure handle ( note, this is with the default tag of 'figure1' that GUIDE gives - I always rename this so this should be whatever the main figure's 'Tag' is).

Then in the OpeningFcn of the SubGUI just store e.g.

handles.mainGUIHandle = varargin{1};

guidata( hObject, handles )

Then the handles of the main GUI can always be retrieved in any callback by calling

mainGUIHandles = guidata( handles.mainGUIHandle );

[Adam]

As for nicer ways to handle things, I use the OOP-based method that I referred to in my comment above (to the original question). I have mentioned it in response to numerous questions, but always saying it was complicated and I didn't have the time to give an example. On the occasion in that thread though I decided to finally put together an example.

I'm sure there are improvements that can be made, but the essence of it is that underlying objects should control the data and calculations and each UI should only be interacting with those, never with each other. It is none of one UI's business what another UI is doing - each reacts to or dictates to the underlying objects.

So if something changes in the 2nd UI, it's callback will change a data property of an underlying object that is also shared with the main UI. The main UI will be listening for changes to this property (or for some event that it triggers) and will react appropriately. Communication in the other direction can be achieved equally.

[Jan]

Thanks, Adam.