Doug's MATLAB Video Tutorials

December 10th, 2010

This video shows how to go and capture the state of the GUI, store it for later use and then restore it.

By Doug Hull

Doug first used MATLAB in 1994, could not figure it out until he got some help in 1995. He is now dedicated to making sure that no one else wastes a year of their life not knowing MATLAB like he did.

18:56 UTC | Posted in Format: Video, Level: Advanced | Permalink | 7 Comments »

You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.

7 Responses to “How to save and restore state of a GUI in MATLAB”

1. Paulo Silva replied on December 10th, 2010 at 21:21 UTC :
   

   Great tutorial, thanks for sharing it with us :)

   Best regards

2. yan replied on December 14th, 2010 at 07:11 UTC :
   

   In a GUI, How can I stop one program running without exiting the GUI (and also keep the current GUI state)? In my programs, I only can stop programs running with ‘ctrl + c’ to kill the programs, Anyway I can dot it?

   Thanks

3. Lior Cohen replied on December 14th, 2010 at 11:19 UTC :
   

   I published a while ago, in the file exchange, a uiremember and uirestore functions that make it very easily (does all the work for you).
   Here is the link –

   http://www.mathworks.com/matlabcentral/fileexchange/24669-gui-with-memory-uiremember-uirestore

4. dhull replied on December 16th, 2010 at 14:51 UTC :
   

   @yan,

   ctrl-c will stop running MATLAB programs. A GUI is a running MATLAB program. If one of the GUI callbacks is being run when you hit ctrl-c, that is what you will break out of, but the gui will still be running. I am not sure what you are asking for. What behavior are you seeing now?

   Doug

5. Devin replied on December 18th, 2010 at 15:08 UTC :
   

   My gui only has

   CloseMenuItem_Callback(hObject, eventdata, handles)
   

   Which works fine when I click file>close, but doesn’t get called when I just click the X in the upper right hand corner. I tried adding a

   CloseRequestFcn_Callback(hObject, eventdata, handles)
   

   But that never gets called. Am I using a different type of GUI? How do I add a CloseRequestFcn that actually gets called?

6. dhull replied on December 20th, 2010 at 15:19 UTC :
   

   @Devin,

   Please send the code to

   http://www.mathworks.com/support

   Doug

7. Brett replied on December 22nd, 2010 at 20:40 UTC :
   

   I required the functionality of saving and restoring the state of a gui and approached the problem in a similar fashion to what Lior Cohen suggested above and posted on the file exchange.

   I looped through the handles structure of the current gui using

   ishandle to weed out non graphics handle fields and
   

   ismember(get(h.(handleName{i}),'type'),{'uicontrol','uimenu','uitable'}) to look for gui components with readily changeable values.  Then I used switch-case structures to filter the "type" and for uicontrols the "style" in order to determine which properties to save/restore.

   This is basically the same functionality offered by Lior's code on the File Exchange, though Lior's only looks at uicontrols and doesn't handle uitables or the "checked" property of uimenus. Lior's code does have the advantage of offering custom options through inputs to the remember function.

   Another common gui state to save and restore is the position, which is a property of the figure itself instead of any of the child components.

   In some cases if a sub-GUI (like a settings dialog) is being dismissed and may be called up again later by the parent GUI it may be possible to simply hide it by setting 'Visible'='off' in the close function and then the next time the sub-GUI is called by the main GUI, the main GUI checks to see if the sub-GUI is already active and if so simply sets 'Visible'='on'. Of course the close function of the main GUI would need to include code to close any lingering sub-GUI's that could still be hidden.

Leave a Reply

<pre class="code">
a = magic(3);
sum(a)
</pre>

These postings are the author's and don't necessarily represent the opinions of The MathWorks.