How to transfer data from one GUI to a uitable of another GUI

i have a main gui with a push button and a uitable. when i click the pushbutton it will open another GUI that contains edit boxes and a pushbutton. The idea is that when i fill out the edit boxes and click the pushbutton of the second GUI it will transfer the generated result/data back to the uitable of the main GUI.

I hope this clarifies the problem. thanks

Answer 1

[Adam]

There are a few different methods. This is a very very rough sketch of the setup I use. I have answered a few questions similar to this saying that OOP is my recommended solution, but that it is too complicated to explain for someone who doesn't know it, but today I figured I would try to give the most simple outline.

This is rushed off from the top of my head so apologies for any errors or omissions. If you wish to try to OOP approach I will try to answer any questions if you get stuck (or other OOP 'experts' can also - I'd certainly never consider myself an expert, but relatively experienced with OOP by now!).

https://www.mathworks.com/help/pdf_doc/matlab/matlab_oop.pdf

is an excellent guide and I recommend using things like property access specifiers and set functions with validation etc to tighten up your code and reduce bugs, but that is all extra to the basic solution.

In a separate file define this class. The properties will be whatever you would call the variables that the data from your edit boxes will fill. I would recommend more meaningful names throughout of course.

classdef SecondGUIStuff < handle

   events
      StuffChanged
   end

   properties
      param1;
      param2;
      ...
   end

end

Note the class derives from the 'handle' base class. This allows it to be passed by reference which is crucial and also to be able to fire off events that can be reacted to elsewhere.

In your first GUI, create an object of this class, store on handles, and in your pushbutton callback pass it as an argument to your second GUI. We also add a listener which will deal with the communication from the 2nd GUI:

In e.g. OpeningFcn:

handles.parameters = SecondGUIStuff;
handles.paramListener = addlistener( handles.parameters, 'StuffChanged', @( src, evt ) updateTable( handles.figure1 ) );

Note: figure1 is the default tag of your GUI in GUIDE. I always change this (to be the same as the GUI name) so if you have changed your GUI tag then change this accordingly.

In callback:

function pushbuttonCallback(...)

MySecondGUI( handles.parameters );

Then create the callback function that will update the table:

function updateTable( hGUI )

handles = guidata( hGUI );

% update your uitable here by accessing handles.parameters.param1 etc..

In MySecondGUI, store that input (varargin{1}) on handles and then in your edit box callbacks or when you click the push button on the second GUI, put the data from your edit boxes into the class e.g.

handles.parameters.param1 = get( handles.edit1, 'String' );
handles.parameters.param2 = get( handles.edit2, 'String' );
etc

Then at the end of the pushbutton callback call

handles.parameters.notify( 'StuffChanged' )

This line sends an event telling anything that is listening that something changed. Up above we added a listener in your first GUI which triggers a callback to update your table in response to an event change. Because the class used derives from handle and is passed by reference, the object stored in your first GUI and that in your 2nd GUI are the same so in your first GUI you have access to the parameters you just filled up in the 2nd GUI.

If you wanted to be able to also change these in the first GUI then you would need a listener in the 2nd GUI also to avoid it getting out of sync with the underlying object. Obviously the object can be changed programmatically too, it just depends how tight you want your control to be. Usually I don't handle this because changing of the parameters in that manner is not supported by my workflow.

[mark]

Interesting solution, Adam. Thank you for this. I'm sure this will solve the problem more than anything else I have tried. Unfortunately,I only heard about OOP but haven't really studied it yet.You are right about this being too complicated for someone who doesn't know it yet.

Could you please provide a simple working example of this solution. As simple as maybe the 2nd GUI will perform an addition to the numbers we input to at least 2 edit boxes when we click the button and then pass the result to the uitable of the first GUI.

This will really accelerate my understanding of OOP in addition to the matlab resource you provided.

Thank you very much.

[Adam]

I have attached the 5 files that should show a simple example of this in action. There are two GUIDE GUIs and the simple class that allows the communication.

I have added comments to hopefully explain what each bit does - there aren't many parts to it though.

Note that I renamed the tag of each GUI to MyFirstGUI and MySecondGUI which is why I pass handles.MyFirstGUI to the callback. If you don't rename it then use handles.figure1 here, but I don't recommend that.

There are plenty of enhancements that you can do to this simple setup, of course. You can force the parameter window to be modal if you wish, but I tend to always like mine to be able to be opened whenever the user wants and remain open if they choose. Note that if the 2nd GUI closes it reopens with the correct state from the first GUI which is embedded in the underlying object. Both GUIs take their data from the object, they don't interact directly with each other.

This setup works on the idea of changing a bunch of parameters and having to then hit an 'Apply' button.

I use this often because I have parameter UIs with many things that may be changed and I don't want my workflow rerunning itself in response to each individual change.

If you wish you can set it up so that as soon as you change a parameter in the 2nd UI (e.g. move the slider) it will immediately update in the first UI and then you don't need the apply button. This depends on your setup and how computationally expensive each update is.

I can provide an example of how to do the latter - there are a couple of ways:

1. Use the same 'StuffChanged' event each time, but do it in the editbox or slider callbacks (this is simple, but less useful at the listener end)
2. Use property listeners so that you can listen to each individual property changing and react to each of those potentially in a different way. This is more coding, e.g. you may attach 3 listeners, one for each of 3 properties, but it gives fine control as you know exactly what changed rather than just a global event telling you that 'something' has changed

Hope this helps. Since it is weekend I had some time spare to put this together that I wouldn't have during the week when I am at work.

[mark]

Thank you for this.Im having problems viewing the .fig files (MyFirstGUI.fig and MySecondGUI.fig). They're all symbols when I view them. I tried copying the .m files to matlab but could not run them because it needs the .fig files.

Could you please email the files instead (<mailto:[e-mail] [e-mail]>).

[Adam]

If you right-click on the file and 'Save link as' you should be able to save it to where you choose and then open it using GUIDE from within Matlab.

[mark]

awesome job, Adam. OOP is on my priority study list.This is definitely what i wanted to implement on a project I am working on. I'll put your name on the acknowledgements when it is completed. But for now I'll be asking some more questions when I get stuck..if you won't mind.

Thank you and have a happy holidays!

[Adam]

No problem. My responses may be a little on and off since I just drop in to Matlab Answers for occasional breaks during my work while I let whatever I am working on sink in, but I will endeavour to respond when I can.