Porting a very old GUI to current versions and using the application compiler

Under windows 7 and 10 I have a matlab GUI from 2009 that is in daily production use with folks running matlab from that era. I have managed to get it working under 2015B with as few interface changes as possible and just as I thought I was done, I've been asked to package it up using the application compiler to send to standalone users.

I'm not sure if my problem is with the application compiler or with the structure of the original gui.

The application compiler shows a splash screen and then stops. I think that it's performing correctly.

There are other files involved, but the GUI consists primarily of three files GUI.m, GUI.fig and GUI_CALLBACK.m. Many of the interface elements call a dispatching GUI_CALLBACK routine that uses a switch statement to get to the code of that element.

The GUI is currently running by clicking on the GUI.fig from explorer (or a shortcut to the fig file) Yes. I'll say that again. The GUI is currently run by clicking on the fig file from explorer. Running GUI.m from the command line does not invoke the gui.

Sans comments the entire contents of GUI.m is

function varargout = Grading_Gui(varargin)
gui_Singleton = 1;
gui_State = struct('gui_Name',       mfilename, ...
                   'gui_Singleton',  gui_Singleton, ...
                   'gui_OpeningFcn', @Grading_Gui_OpeningFcn, ...
                   'gui_OutputFcn',  @Grading_Gui_OutputFcn, ...
                   'gui_LayoutFcn',  [] , ...
                   'gui_Callback',   []);
if nargin && ischar(varargin{1})
    gui_State.gui_Callback = str2func(varargin{1});
end
function Grading_Gui_OpeningFcn(hObject, eventdata, handles, varargin)
handles.output = hObject;
guidata(hObject, handles);
function varargout = Grading_Gui_OutputFcn(hObject, eventdata, handles) 
varargout{1} = handles.output;

I can mimic much of the functionality of the GUI with a new guide-built mimic where all of the callbacks will be in MIMIC.m and MIMIC.m will contain.

if nargin && ischar(varargin{1})
    gui_State.gui_Callback = str2func(varargin{1});  
end  
if nargout
      [varargout{1:nargout}] = gui_mainfcn(gui_State, varargin{:});
else
      gui_mainfcn(gui_State, varargin{:});  
end

This mimic of the GUI will package up correctly using the application compiler.

Placing calls to gui_mainfcn in GUI.m creates a world of confusion when the m file is called. Trying to extract the callbacks from GUI_CALLBACK.m and create new guide inspired version in GUI.m doesn't succeed.

Any ideas on how the fig file is running the m files?

Any ideas on the best way to get an application compiled version of this w/out going back to the drawing board and recreating a fully new GUI that might behave subtly differently than the old version and end up being rejected by current users?

[Geoff Hayes]

David - The GUI is currently running by clicking on the GUI.fig from explorer (or a shortcut to the fig file. Unless something has changed with R2015b, the GUI is not meant to be run/executed by double-clicking on the *.fig file. It can be run by calling (from the Command Window) the name of the GUI, or it can be executed in the MATLAB editor by pressing the run button (when editing the *.m file), or it can be executed from GUIDE.

When you just double-click the *.fig file, it is only the figure that will be displayed (much like the figure that is the result of plotting data) and none of the necessary initializations will occur.

What does happen when you try to run the GUI from the command line. What are the error messages?

[David Short]

"When you just double-click the *.fig file, it is only the figure that will be displayed (much like the figure that is the result of plotting data) and none of the necessary initializations will occur."

I can very much assure you that in this case you are mistaken. Remember this gui and its associated fig file are very old. Now, my newly created mimic file behaves exactly the way that you describe (and will package up using the application compiler too). Double clicking on the original GUI.fig file starts the gui with several very functional screens as described in my original message. Why this is the case is kind of the crux of my question.

"What does happen when you try to run the GUI from the command line. What are the error messages?"

No error message. No gui on the screen. The commentless version of GUI.m appears in my original post. It differs from the mimiced version exactly by the lines that appear to invoke the gui.

[Walter Roberson]

The behaviour of needing to invoke the .m file instead of the .fig described here predates the 2009 releases.

The behaviour can be worked around by modifying the figure creation callback, but that does not appear to have been done here.

[David Short]

Walter....It is possible that the files in question are from as far back as 2006.

[Walter Roberson]

Needing to invoke the .m file predates 2006. It has probably always been true for GUIDE.

[David Short]

If I understand you correctly ... the original builder of the gui has found a way around the default behavior so that in this case running the m file does nothing and running the fig file starts the gui.

Any idea how (or why) they did that so I can reverse that behavior?

I WANT the default behavior so the gui can be bundled up and run correctly through the application compiler.

[Walter Roberson]

In theory it could be done by modifying Grading_Gui_OpeningFcn or one of the other *OpeningFcn as those graphics objects come into existence and so have their CreateFcn callbacks executed when the .fig is openfig()'d

I have not investigated GUIDE extensively; I used it a small number of times a number of years ago, and I have poked at it from time to time to answer Questions here. Still, I might be able to figure out how the existing one works.

I am running R2014a so there is a possibility that it might just work for me without modification. Perhaps.

I suggest you .zip the files and attach it here. Or you could send me a link to the .zip through my profile here.

[David Short]

ygm