Save the state of a GUI between session

Six minute video shows how to save and restore the state of a GUI

Description

This short video shows you how to save and restore the state of a GUI by GETting the value of all the UICONTROLs of interest and then saving them in a structure in a .mat file. Later, you can restore the state by loading this m-file and SETting the values of the UICONTROLs. Buttons are used to save and load for simplicity at the beginning, but later the save and restore is associated with the opening and closing functions of the GUI.
 
See more videos without downloading here: http://blogs.mathworks.com/pick/category/video

• MATLAB release: MATLAB 7.6 (R2008a)
• HTML Files: Video from http://blogs.mathworks.com/pick

Other Files

126 Advanced Save state gui.flv,
mCode/main.mat,
126 Advanced Save state gui.js,
126 Advanced Save state gui_config.xml,
126 Advanced Save state gui_controller.swf,
126 Advanced Save state gui_nofp_bg.gif,
126 Advanced Save state gui_preload.swf,
mCode/main.m,
ProductionInfo.xml,
swfobject.js,
mCode/main.asv,
mCode/main.fig,
FlashTemplate.css

[Ilya R]

This doesn't seem practical if one has very complicated GUI with many widgets. Wouldn't just saving and loading .fig file be simpler?

[Doug Hull]

Ilya,

I agree, there are advantage and disadvantages of this versus saving the fig file. For some, that might be a fine solution.

Some people like having a human readable save file. While there is more maintenance (updating the saveState and restoreState) this is a very readable and understandable method that can be customized to a great degree. Sometimes there is state associated with the GUI that is not reflected in the state of UICONTROLs.

-Doug

[Geoff Dutton]

What are the use cases for this approach? One comes to mind: send the MAT-file to another user with the same GUI to synchronize or initialize for some joint project. However, this might not be so practical if data or graphs are embedded in the GUI.

I agree with Ilya that saving the GUI as a FIG-file seems more practical. That approach isn't recommended, apparently, but I don't know of any reasons not to do so. Loading the FIG-file restores the state of everything (BTW, GUIDE isn't needed for this, just a FIG-file and an M-file with the callbacks).

[Doug Hull]

After posting this, I poled the GUI Building Team members for their opinions. Just as here, I found that there are two camps: those that advocate HGSAVE to save a figure file and the explicit query and save technique.

HGSAVE is a simple solution, and will work for many people that are using GUIDE.

The technique I outlined also works, but does take more effort to construct and maintain. One of the advantages is that it keeps the data separate from the .FIG file used in the creation of the GUI. I find that appealing, as do many others.

Also, if someone were making a GUI programmatically, they never explicitly load a .FIG file, so the HGSAVE method would not be as applicable.

-Doug

[Geoff Dutton]

I have a comment about "Also, if someone were making a GUI programmatically, they never explicitly load a .FIG file, so the HGSAVE method would not be as applicable."

This isn't necessarily true. I can easily conceive of a programmatic GUI that, having set up a GUI and added some data to it, allows the user to save the figure (or the user can do this from the CL). When that M-file runs, it could look for the saved figure or prompt the user to identify it, and then bypass its setup code. My ListMaster example does this, more or less; it knows if the currently open figure contains data or not.