Saving multi-form GUI data into .MAT -- appropriate approach?

Background:

I'm working on a GUI that imports data that is output from a specific program. The type of data isn't important; the purpose of the GUI is to allow users to package other information alongside the data in a way that's easy to view (includes surveys, demographic information, comments, etc). The final output of this program is a .MAT file with a very large handle structure containing everything. In the past this application was written so that all of the information was present on a single form, with abundant hiding and displaying (So a survey would be on one frame, a different survey would be on different frames behind it). It was cumbersome, and because the program was so large, MATLAB had troubles handling all of it. I underwent the painstaking process of splitting everything into separate forms, and allowing the user to load whichever forms were needed from the launch of the program.

I am aware that this project has a lot of redundancies and things that will make you think "are those steps REALLY necessary?" For instance, I don't know if appdata saves when you save a .MAT file--but even if it does, I still have to write it so that all element data is saved to and loaded from the handles structure, because that's how previous files were saved. I don't have any say in the matter; at this point I just need to finish this thing to the specifications.

Problem description:

When dealing with information across multiple forms, I've concluded that using root appdata is probably the best approach. It's the next best thing to global variables (In fact, it IS global variables if my understanding is correct), and I don't want the hassle of passing handle functions from form to form. On any individual form, the starting code checks for any existing data and sets the elements to the appropriate values. It's the saving that's been giving me the most headaches.

Having a button that tells the sub-GUI to save GUI elements into appdata on each form is probably the easiest way to deal with this, but I was having all sorts of problems in the form's close function when trying to remind a user--"Hey, don't forget to save!" (I might come back to this on a different thread, it's not important here). The ideal approach, in my mind, is to have everything save whenever the user makes a change. Two approaches to this: 1) use the callback functions to set appdata per individual element update, or 2) creating a continuously updating function that is constantly storing the element info into appdata (taking a page from my knowledge of game programming).

The benefit to the individual functions approach would be that the code would not be looping continuously, and user would not have to worry about saving changes except for on the main part of the GUI. The drawback is, I don't think there's a callback function for every time a text field or similar elements change (I've been scouring these forums looking for an answer). If there were a simple function for off-click, this approach would be so much easier.

The second, 'frame update' approach would loop for every nth of a second or so, where n is a sufficient number that does not cause the system to lag. I would prefer this approach, but I don't know how to implement it into a MATLAB GUI (Created by GUIDE btw). I've done things like this in the past with a while(true) loop, but I don't even know where I'd even put that code in the mess of an M-file GUIDE spits out. I'm assuming after the start function and the part where I initialize everything...

Anyway, my naive intuition tells me I want to go with the continuous updating function, because then I could include all parameters in one neat block of code, instead of having to wade through several callback functions. But GUI programming in MATLAB has been trickier than I anticipated. If anyone can give me some concrete advice pertinent to this particular problem, it'd be greatly appreciated.