How do I create a GUI with a sequence of windows, navigating using "Back" and "Next" pushbuttons?

I want to create a GUI which works as a setup program for a simulation using a already constructed models. There are a bunch of parameters that needs to be set before a run, as well as files that needs loading, etc. and doing all of this in one window is not very pretty (cluttered and huge window is a no, no). Instead I would like to create a GUI that guides the user through the process.

An example could be:

 Window 1
   Pick what data file you want to use for the simulation, using a pushbutton and uigetfile().
   Choose what kind of simulation you want to run (what model you want to use), using a group of radio buttons or a drop down menu.
   Press Next to move to Window 2 (or Cancel to quit)

.

 Window 2
   Given what model was picked, show the parameters required for that model.
   Press Back, Next or Cancel

.

 Window 3
   Show a final window with generic parameters required by all models.
   Press Back, Run or Cancel

I have looked at some example programs showing how to change data between programs , but I don't get it. I don't know if the issue is GUIDE or the relation between GUIDE and the rest of matlab, but I cannot figure out how this is supposed to work.

Any suggestions regarding how something like this could be implemented is greatly appreciated. Also, any material that thoroughly goes through how application programming in Matlab works is welcomed. I have been trying to use the documentation , but somehow I cannot wrap my head around it.

Thank you.

[Adam]

I have tended to use the GUI Layout Toolbox in combination with uitabs (unsupported in GUIDE) for a programmatic UI defined in a class (or rather a suite of classes, but it could all be in one) to do this.

https://uk.mathworks.com/matlabcentral/fileexchange/47982-gui-layout-toolbox (post R2014b (inclusive) )

https://uk.mathworks.com/matlabcentral/fileexchange/27758-gui-layout-toolbox (pre R2014b)

This does involve a lot of programming though and takes a while to get used to. It isn't necessary to use the GUI Layout toolbox as tabs are independent of this, but I don't enjoy creating programmatic UIs having to explicitly position every component and control its resizing etc.

Some people do programmatic GUIs just in a function rather than a class too, but this is best for something quite simple, I would much rather use a class.

Answer 1

[Adam]

This recent question might help:

https://uk.mathworks.com/matlabcentral/answers/312278-how-to-change-the-gui-content-when-selecting-different-menu-buttons

If you have everything in one GUI communication is certainly easier because all the guidata stuff works very cleanly.

Working with different figures you can also go down a guidata route. It is something I would never do myself and seeing my team-mates do this some years ago when we built our first significant multi-window tool was what triggered me to learn about Matlab OOP because there was no way I wanted to work on code that did the kind of things this was doing.

However, you can still do it in a bit of a neater way. Whenever you launch one of your new GUIs pass into it the tag of the current GUI (or the main GUI, whichever one needs to communicate with the spawned GUI). Then you can access its handles from that tag using guidata and avoiding having to use some ghastly findall(...) type solution.

The problem still remains though of actually communicating. This is where classes/objects work very neatly. Done properly the part of the program that wants to respond to an action should be listening to changes in some property, but I'm not sure about how this works when you are using the handles struct of different GUIs because you can't add a listener to a structure field per se.

If you wish to save to file then a .mat file makes most sense, but you will still have the problem of defining message passing for another part of the program to know when something has changed that it is supposed to respond to. You can, of course, write your own listener type functions, i.e. basically callbacks and I have also done this before, but again I do it in a class framework where such things are so much easier.

[Erik Thorsell]

I considered the visibility "trick" too, but it gets so cluttered... Maybe this is the time to learn Matlab OOP after all. I was hoping there was an easier way, but hey - there's a time for everything. You don't happen to have a Matlab OOP crash course laying around?

[Adam]

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

is what I learned from. Certainly not a crash course, but the basics were quite intuitive and learning all the nuances is a lifetime's work, but I very quickly developed enough expertise to develop the things I wanted to.

In a nutshell what you would want to do is the following:

Have a class that derives from 'handle' (you can look this up in that document or 'doc handle' on command line), but basically this allows your class object to be passed by reference and to be able to fire off events that can be listened to.

This class can be created in your main GUI and have properties that would be filled up in another GUI (e.g. parameters for an algorithm - the algorithm may be run in the main GUI, but the parameters set in a separate GUI - ideally you would have default parameters too).

Then when you launch your parameters GUI you pass this object in. In that parameter GUI you can then set the parameters into this object, either live in callbacks or all at once on an OK button or similar.

Now because the object was passed by reference you also have this object nicely filled with parameters in your original GUI. But of course they have just been quietly set without your GUI knowing anything about it.

So that is where listeners come in. In your main GUI, before you pass this object to your 2nd GUI you attach one or more listeners, either listening for properties being set or for events (doc listener for information on this, or again that OOP document linked at the top of this post). Your listener defines a callback and that callback will then run when the event it is listening for is triggered.

You can add as many listeners as you like with callbacks or you can just add a single listener for one event that you trigger when you have set all the parameters in your object.

That is rather a rushed explanation, but hopefully it gives an idea of the basics of the design. Obviously there are many many variations and ways to make it more complicated for different situations, but the core idea is relatively simple.

Answer 2

[Image Analyst]

See if these links help:

http://blogs.mathworks.com/videos/category/gui-or-guide/

http://www.mathworks.com/matlabcentral/fileexchange/24224

Also, is this homework? Because it looks like it. Please add a homework tag if it is.

[Erik Thorsell]

Thank you, I will look at this tomorrow. And no, no homework, work though.

[Erik Thorsell]

I realized "tomorrow" actually meant "next week", it's been hectic.

Thank you for your links, however I was not really able to utilize them to any greater extent. I have gotten a bit on my the way though but I have reached "sharing information between different figures" again and have an idea.

If you look at the print screen attached you see one figure. The plan is that the GUI should open with this view active. You should then be able to navigate freely between the figures using the buttons at the top of the GUI. The buttons all present similar figures as the one attached, the idea is that you can choose your preferred settings on each view.

I see before myself a binary file that contains all the variables (each radio button, each editable text field, etc) that will ultimately be passed to the model. When the GUI is first opened the binary file is created (or overwritten with a clean one if already existing) and then all the choices made are written to that binary.

This far I have:

• Created a figure corresponding to each of the buttons (except Load File and Run).
• In each figure created button groups and editable text fields corresponding to what the model expects.
• Written "setup functions" s.t. when a radio button is pressed the editable fields are filled in with standard values corresponding to that choice.

What I want to do next is to utilize my binary file approach to share the data between the figures. However, when I read online and in the documentation I find nothing about this. Instead guidata is mentioned a lot. However, I don't see how it fits my use case.

Question

Is my idea point blank bad, or is there something to it? Regardless, I need a pointer in the right direction as to how to store data, and transfer values between figures. For instance, how can I store get(hObject,'Tag') and get(hObject,'String') in a binary file, in a way s.t. I can update it and read it back as I wish?

[Erik Thorsell]

I tried to create a map (containers.Map) which I in turn update with every tag and string/value in the figure. The plan is then to write the map to a file but apparently fwrite does not support writing a map to file. Am I just digging myself a hole here, or can this be done?

[Image Analyst]

Regarding "sharing data" between functions in a single m-file, or between different m-files/guis, you might explore several ways listed in the FAQ: http://matlab.wikia.com/wiki/FAQ#How_can_I_share_data_between_callback_functions_in_my_GUI.28s.29.3F

You might also explore the use of tabbed interfaces with uitab(). Or try the new GUI development tool called App Designer.