Avoid saving multiple figures when trying to save a figure prompted by a GUI as .fig?

I have a complex GUI that is used to generate multiple plots and figures. Let's call the main GUI figure handles.figureMain and the figure generated by a callback in the main GUI, handles.figurePlot.

In figurePlot, selecting File>Save As... *.fig creates a .fig file that includes both figures: figureMain and figurePlot.

How can I make sure only figurePlot is saved in the .fig file?

Things I have tried that haven't worked:

• Turning off handle visibility to figureMain

 handles.figureMain.HandleVisibility = 'Off'

• Turning off graphical visibility to figureMain before saving

handles.figureMain.Visible = 'Off'

• Modifying the File>Save As... menu item in figurePlot to a modified callback function that invokes savefig instead of saveas .

hMenuFile = findall(handles.figurePlot,'type','uimenu','tag','figMenuFile');
hSaveFigure = findall(handles.figurePlot,'type','uimenu','tag','figMenuFileSaveAs');
set(hMenuFile,'Callback','filemenufcn_custom FilePost')
set(hSaveFigure,'Callback','filemenufcn_custom(gcf,''FileSaveAs'')')

(I have also tried gcbo instead of gcf .) Then in filemenufcn_custom > localSaveExportHelper :

if strcmp(types{typevalue,4},'fig') && ~fromExport
  savefig(hfig, filename, 'compact')
  % saveas(hfig,filename); % original/replaced code 
else 
...

• Setting the InSaveFig property of figureMain to 'Off'

set(handles.figureMain,'InSaveFig','off')

• I have also checked children and parents, and tracked down the figure handle all the way until it is written using FF.write() in savefig and I cannot find any reason why handles.figureMain should be included in saving handles.figurePlot as a .fig.

The only thing that works (partially) is actually closing figureMain before saving figurePlot but this isn't feasible for my purposes.

Saving the additional figure is quite costly in terms of time and memory so a solution would be appreciated.

Thanks.

[Walter Roberson]

Is it really necessary to support File->save as, when you could put in your own buttons with whatever callback you need?

Is it possible that that FigurePlot has attached to one of its graphic objects a reference to some part of FigureMain?

[Gil Zimmerman]

Even when calling savefig outside of File->Save As... the function saves both figures.

How would I be able to look for a reference to figureMain that's attached to a graphic object in figurePlot? I've gone through everything in figurePlot's structure and couldn't, at least superficially, see anything related to figureMain.

[Walter Roberson]

Can you attach the fig ? Zip them if you need to.

I will not be able to analyze fig until afternoon my time, but I do have some tools to help me dig.

[Christoph Neumann]

puh, nealy three years ago and no solution? I have the same problem with R2019b.

I could provide the saved *.fig but not per email, since it's size is 200MB.

[Christoph Neumann]

This malfunction appears (in my application) only together with "copyobj", where an axes from the GUI main window is copied to the separate figure. In this case, "saveas" or "savefig", addressing the separate figure, is saving both the GUI main window and the separate figure.

[Gil Zimmerman]

In my situation, as I recall, I was passing a lot of data through the object handles. When I called savefig, it was saving all that data (that was being processed by the GUI) into the .fig file. The fix was to find where the data was being passed into handles, and instead pass only the fields of handles that were needed for processing. I know this is a vague solution, but it was 3 years ago. Generally, manage where your data is being stored and make sure it is separated from the data that is being saved.

Answer 1

[Gil Zimmerman]

From an email conversation to debug:

"I couldn't attach the figure files as is... so I set about creating a generic sine plot instead. That's when I saw that the generic plot wasn't replicating the issue, so I tested all of the figures I generated and learned that the issue was confined to histograms.

The histogram figures contained a number of elements: the histogram, a data tool-tip with custom toot tip function, a plot on top of the histogram, and a custom menu item to export data from the histogram to an excel file. I turned off each in turn to see which was causing the huge files and narrowed it down to the menu, of all things.

It turns out that in the data export function I wrote, I was passing the catch-all structure "handles" in order to reference 3 or 4 minor fields. As you know, the structure handles includes all data, graphics, and anything in memory associated with the program and it was being saved as part of the fig. To resolve the issue, I passed the individual fields I needed instead of the whole structure. Problem solved."