Thread Subject: Compiled Matlab Applications - Missing Functions

Hi all,

I have developed an application in MATLAB consisting of a UI (developed using GUIDE) and some underlying functions invoked by callbacks from the main UI.

The export m-file generated by GUIDE for the UI is then compiled to generate an exe that clients can run using the MATLAB MCR.

I have a couple of questions relating to this process:

1. Is there still a requirement in MATLAB R2011b to use %#function definitions to identify all functions that your application is dependent upon for compilation purposes? I'm guessing there is, as I am getting a lot of 'missing function' error messages at runtime as a result of missing %#function statements.

2. Is there an easy way to determine all of the dependencies from a top-level GUIDE generated UI? I know of 'Tools-Show dependency report' but this does not work with m-files created using the GUIDE export function.

Thanks in advance for any response.

Cheers,

Scott

"Scott" wrote in message <jgba4t$ie5$1@newscl01ah.mathworks.com>...
> Hi all,
>
> I have developed an application in MATLAB consisting of a UI (developed using GUIDE) and some underlying functions invoked by callbacks from the main UI.
>
> The export m-file generated by GUIDE for the UI is then compiled to generate an exe that clients can run using the MATLAB MCR.
>
> I have a couple of questions relating to this process:
>
> 1. Is there still a requirement in MATLAB R2011b to use %#function definitions to identify all functions that your application is dependent upon for compilation purposes? I'm guessing there is, as I am getting a lot of 'missing function' error messages at runtime as a result of missing %#function statements.

To my knowledge no.

>
> 2. Is there an easy way to determine all of the dependencies from a top-level GUIDE generated UI? I know of 'Tools-Show dependency report' but this does not work with m-files created using the GUIDE export function.

The compiler dependency analyser works pretty well, unless if the code use EVAL, FEVAL with strings, change the default, pathname, change the callback, etc.. anything that Matlab cannot guess. The suggestion is to avoid using such awkward programming.

Bruno

"Scott " <smiffos@nospam.hotmail.com> wrote in message
news:jgba4t$ie5$1@newscl01ah.mathworks.com...
> Hi all,
>
> I have developed an application in MATLAB consisting of a UI (developed
> using GUIDE) and some underlying functions invoked by callbacks from the
> main UI.
>
> The export m-file generated by GUIDE for the UI is then compiled to
> generate an exe that clients can run using the MATLAB MCR.
>
> I have a couple of questions relating to this process:
>
> 1. Is there still a requirement in MATLAB R2011b to use %#function
> definitions to identify all functions that your application is dependent
> upon for compilation purposes? I'm guessing there is, as I am getting a
> lot of 'missing function' error messages at runtime as a result of missing
> %#function statements.

Sounds like you're running into this:

http://www.mathworks.com/help/toolbox/compiler/br2cqa0-2.html#br2cqa0-5

Personally I'd suggest the "use function handles" solution described in that
document, but if that's not an option using the %#function pragma is another
solution.

> 2. Is there an easy way to determine all of the dependencies from a
> top-level GUIDE generated UI? I know of 'Tools-Show dependency report' but
> this does not work with m-files created using the GUIDE export function.

It should, as long as you're not calling a function using EVAL or FEVAL with
a string containing the name of the function or anything like that, again as
described on the page to which I linked above.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Hi Steve,

The problem is, as the article eludes to, that GUIDE outputs its callback functions as strings, so the compilers dependency search misses them.

I could go into the exported m-file and change all occurrences of the type " 'CallBack','change_colormap' " to " 'CallBack', @change_colormap " as the article suggests, but next time I export the file, these changes would be overwritten.

I think the safest way for me is to use a %# function statement for all the callbacks.

Thanks for the advice and pointer to the article.

Cheers,

Scott

"Steven_Lord" <slord@mathworks.com> wrote in message <jgbhqh$e3p$1@newscl01ah.mathworks.com>...
>
>
> "Scott " <smiffos@nospam.hotmail.com> wrote in message
> news:jgba4t$ie5$1@newscl01ah.mathworks.com...
> > Hi all,
> >
> > I have developed an application in MATLAB consisting of a UI (developed
> > using GUIDE) and some underlying functions invoked by callbacks from the
> > main UI.
> >
> > The export m-file generated by GUIDE for the UI is then compiled to
> > generate an exe that clients can run using the MATLAB MCR.
> >
> > I have a couple of questions relating to this process:
> >
> > 1. Is there still a requirement in MATLAB R2011b to use %#function
> > definitions to identify all functions that your application is dependent
> > upon for compilation purposes? I'm guessing there is, as I am getting a
> > lot of 'missing function' error messages at runtime as a result of missing
> > %#function statements.
>
> Sounds like you're running into this:
>
> http://www.mathworks.com/help/toolbox/compiler/br2cqa0-2.html#br2cqa0-5
>
> Personally I'd suggest the "use function handles" solution described in that
> document, but if that's not an option using the %#function pragma is another
> solution.
>
> > 2. Is there an easy way to determine all of the dependencies from a
> > top-level GUIDE generated UI? I know of 'Tools-Show dependency report' but
> > this does not work with m-files created using the GUIDE export function.
>
> It should, as long as you're not calling a function using EVAL or FEVAL with
> a string containing the name of the function or anything like that, again as
> described on the page to which I linked above.
>
> --
> Steve Lord
> slord@mathworks.com
> To contact Technical Support use the Contact Us link on
> http://www.mathworks.com

On Feb 2, 3:09 am, "Scott " <smif...@nospam.hotmail.com> wrote:
> Hi Steve,
>
> The problem is, as the article eludes to, that GUIDE outputs its callback functions as strings, so the compilers dependency search misses them.
>
> I could go into the exported m-file and change all occurrences of the type " 'CallBack','change_colormap' " to " 'CallBack', @change_colormap " as the article suggests, but next time I export the file, these changes would be overwritten.
>
-----------------------------------------------------------------------------
I don't believe that's true and I didn't see anywhere in the article
where it said GUIDE outputs its callbacks as strings. GUIDE puts in
an actual callback function right into the m-file. It doesn't have a
bunch of uicontrol() calls to build controls and list the callbacks
inside that uicontrol as strings. The callbacks are right in there
just like any other function. Like I said in your other posting, I
compile GUIDE apps all the time and it's fine.

I agree with Steve when he said that it should only be a problem if
you have a string with a function name in it that is being executed
with an eval() or feval() call, because the Dependency tool will
consider that just some generic character string, like any other
arbitrary string. It doesn't know that in that context the string
refers to a function.

ImageAnalyst <imageanalyst@mailinator.com> wrote in message <9dfcc750-e290-4bf9-889f-6791229538bb@pk8g2000pbb.googlegroups.com>...
> On Feb 2, 3:09 am, "Scott " <smif...@nospam.hotmail.com> wrote:
> > Hi Steve,
> >
> > The problem is, as the article eludes to, that GUIDE outputs its callback functions as strings, so the compilers dependency search misses them.
> >
> > I could go into the exported m-file and change all occurrences of the type " 'CallBack','change_colormap' " to " 'CallBack', @change_colormap " as the article suggests, but next time I export the file, these changes would be overwritten.
> >
> -----------------------------------------------------------------------------
> I don't believe that's true and I didn't see anywhere in the article
> where it said GUIDE outputs its callbacks as strings. GUIDE puts in
> an actual callback function right into the m-file. It doesn't have a
> bunch of uicontrol() calls to build controls and list the callbacks
> inside that uicontrol as strings. The callbacks are right in there
> just like any other function. Like I said in your other posting, I
> compile GUIDE apps all the time and it's fine.
>
> I agree with Steve when he said that it should only be a problem if
> you have a string with a function name in it that is being executed
> with an eval() or feval() call, because the Dependency tool will
> consider that just some generic character string, like any other
> arbitrary string. It doesn't know that in that context the string
> refers to a function.

Hi,

Thanks for the follow-up message, if there is a way to do it automatically, I'm all for it.

From what you have said above, it looks like all of your callback functions are contained within the m-file associated with the .fig GUIDE file - correct? My implementation is slightly different, all of my callback functions are contained in their own m-file.

I'm no MATLAB expert, so maybe you can pick-up a flaw in my process:

1. Use GUIDE to create a user interface (interface.fig)
2. Add a button to the interface
3. Use GUIDE to modify the button callback property to specify the function 'handle_button', which is contained in a separate m-file handle_button.m
4. Save UI from GUIDE (interface.fig & interface.m)
5. Export the UI such that the exported m-file can be compiled (interface_export.m)
6. Compile interface_export.m

In this scenario, the handle_button.m function is not compiled as the compiler cannot pick-up the dependency in the exported m-file, interface_export.m.

This is because the callback is specified as follows in the m-file:

h96 = uicontrol(...
'Parent',h1,...
'Units','normalized',...
'Callback','handle_button',...
'ListboxTop',0,...
'Position',[0.0261780104712042 0.540574282147316 0.0174520069808028 0.0237203495630462],...
'String',blanks(0),...
'TooltipString','Pen plot',...
'Tag','pen_b',...
'CreateFcn', {@local_CreateFcn, blanks(0), appdata} );

and the string 'handle_button' is not picked up by the compiler.

I guess for locally defined callback functions, the compiler can detect these dependencies but this is not true for my callbacks.

If you can see away around this (other than defining my callbacks locally) it would be most welcome.

Cheers,

Scott

"Scott" wrote in message <jgg4pj$pqg$1@newscl01ah.mathworks.com>...

>
> I'm no MATLAB expert, so maybe you can pick-up a flaw in my process:
>
> 1. Use GUIDE to create a user interface (interface.fig)
> 2. Add a button to the interface
> 3. Use GUIDE to modify the button callback property to specify the function 'handle_button', which is contained in a separate m-file handle_button.m

If leave the CallBack property alone, just keep it as the default, then in the interface.m file call your own function in a separate file, it would be fine.

The reason is simple: Matlab compiler can't analyze (GUI) fig file and dig-out the callback in the string form. If you do that, you need to use %#function to inform the compiler, but that way of doing produces a code that is not very easy to maintain.

% Bruno

"Scott " <smiffos@nospam.hotmail.com> wrote in message
news:jgg4pj$pqg$1@newscl01ah.mathworks.com...
> ImageAnalyst <imageanalyst@mailinator.com> wrote in message
> <9dfcc750-e290-4bf9-889f-6791229538bb@pk8g2000pbb.googlegroups.com>...
>> On Feb 2, 3:09 am, "Scott " <smif...@nospam.hotmail.com> wrote:
>> > Hi Steve,
>> >
>> > The problem is, as the article eludes to, that GUIDE outputs its
>> > callback functions as strings, so the compilers dependency search
>> > misses them.
>> >
>> > I could go into the exported m-file and change all occurrences of the
>> > type " 'CallBack','change_colormap' " to " 'CallBack', @change_colormap
>> > " as the article suggests, but next time I export the file, these
>> > changes would be overwritten.
>> >
>> -----------------------------------------------------------------------------
>> I don't believe that's true and I didn't see anywhere in the article
>> where it said GUIDE outputs its callbacks as strings. GUIDE puts in
>> an actual callback function right into the m-file. It doesn't have a
>> bunch of uicontrol() calls to build controls and list the callbacks
>> inside that uicontrol as strings. The callbacks are right in there
>> just like any other function. Like I said in your other posting, I
>> compile GUIDE apps all the time and it's fine.
>>
>> I agree with Steve when he said that it should only be a problem if
>> you have a string with a function name in it that is being executed
>> with an eval() or feval() call, because the Dependency tool will
>> consider that just some generic character string, like any other
>> arbitrary string. It doesn't know that in that context the string
>> refers to a function.
>
> Hi,
>
> Thanks for the follow-up message, if there is a way to do it
> automatically, I'm all for it.
>
> From what you have said above, it looks like all of your callback
> functions are contained within the m-file associated with the .fig GUIDE
> file - correct? My implementation is slightly different, all of my
> callback functions are contained in their own m-file.
>
> I'm no MATLAB expert, so maybe you can pick-up a flaw in my process:
>
> 1. Use GUIDE to create a user interface (interface.fig)
> 2. Add a button to the interface
> 3. Use GUIDE to modify the button callback property to specify the
> function 'handle_button', which is contained in a separate m-file
> handle_button.m

If you mean this literally, that you specify the string 'handle_button' as
the value of the Callback property of your button, I recommend you not do
that. Specify the Callback property as a function handle instead.

> 4. Save UI from GUIDE (interface.fig & interface.m)
> 5. Export the UI such that the exported m-file can be compiled
> (interface_export.m)
> 6. Compile interface_export.m
>
> In this scenario, the handle_button.m function is not compiled as the
> compiler cannot pick-up the dependency in the exported m-file,
> interface_export.m.
>
> This is because the callback is specified as follows in the m-file:
>
> h96 = uicontrol(...
> 'Parent',h1,...
> 'Units','normalized',...
> 'Callback','handle_button',...

Yes. Don't do this!

> 'ListboxTop',0,...
> 'Position',[0.0261780104712042 0.540574282147316 0.0174520069808028
> 0.0237203495630462],...
> 'String',blanks(0),...
> 'TooltipString','Pen plot',...
> 'Tag','pen_b',...
> 'CreateFcn', {@local_CreateFcn, blanks(0), appdata} );
>
> and the string 'handle_button' is not picked up by the compiler.

Yes. The dependency checker that MATLAB Compiler uses doesn't interrogate
each and every string in the file to determine if it's passed into an FEVAL
or specified as the Callback property of a Handle Graphics object or the
like. It does know how to "look for" a function referred to by a function
handle; even if local_CreateFcn were a separate file in your example above,
MATLAB Compiler knows (since the CreateFcn includes a function handle to
local_CreateFcn) to include it in the compiled application.

> I guess for locally defined callback functions, the compiler can detect
> these dependencies but this is not true for my callbacks.
>
> If you can see away around this (other than defining my callbacks locally)
> it would be most welcome.

Use function handles instead.

--
Steve Lord
slord@mathworks.com
To contact Technical Support use the Contact Us link on
http://www.mathworks.com

Steve,

Thanks for the follow up.

Just to be clear, I am not writing the code for the uicontrol, it is being generated by MATLAB when I export a GUIDE figure.

In the GUIDE IDE, I can specify the callback property of a uicontrol but it doesn't matter if I just use handle_button or @handle_button, it is still wrapped up as a string when the figure is exported.

Is there a way to specify the callback property of a uicontrol from GUIDE such that when it is exported, it is not wrapped in a string?

Cheers,

Scott

> > 1. Use GUIDE to create a user interface (interface.fig)
> > 2. Add a button to the interface
> > 3. Use GUIDE to modify the button callback property to specify the
> > function 'handle_button', which is contained in a separate m-file
> > handle_button.m
>
> If you mean this literally, that you specify the string 'handle_button' as
> the value of the Callback property of your button, I recommend you not do
> that. Specify the Callback property as a function handle instead.
>
> > 4. Save UI from GUIDE (interface.fig & interface.m)
> > 5. Export the UI such that the exported m-file can be compiled
> > (interface_export.m)
> > 6. Compile interface_export.m
> >
> > In this scenario, the handle_button.m function is not compiled as the
> > compiler cannot pick-up the dependency in the exported m-file,
> > interface_export.m.
> >
> > This is because the callback is specified as follows in the m-file:
> >
> > h96 = uicontrol(...
> > 'Parent',h1,...
> > 'Units','normalized',...
> > 'Callback','handle_button',...
>
> Yes. Don't do this!
>
> Yes. The dependency checker that MATLAB Compiler uses doesn't interrogate
> each and every string in the file to determine if it's passed into an FEVAL
> or specified as the Callback property of a Handle Graphics object or the
> like. It does know how to "look for" a function referred to by a function
> handle; even if local_CreateFcn were a separate file in your example above,
> MATLAB Compiler knows (since the CreateFcn includes a function handle to
> local_CreateFcn) to include it in the compiled application.
>
> > I guess for locally defined callback functions, the compiler can detect
> > these dependencies but this is not true for my callbacks.
> >
> > If you can see away around this (other than defining my callbacks locally)
> > it would be most welcome.
>
> Use function handles instead.
>
> --
> Steve Lord
> slord@mathworks.com
> To contact Technical Support use the Contact Us link on
> http://www.mathworks.com

On Feb 3, 10:21 am, "Scott " <smif...@nospam.hotmail.com> wrote:
> Steve,
>
> Thanks for the follow up.
>
> Just to be clear, I am not writing the code for the uicontrol, it is being generated by MATLAB when I export a GUIDE figure.
>
> In the GUIDE IDE, I can specify the callback property of a uicontrol but it doesn't matter if I just use handle_button or @handle_button, it is still wrapped up as a string when the figure is exported.
>
> Is there a way to specify the callback property of a uicontrol from GUIDE such that when it is exported, it is not wrapped in a string?
>
> Cheers,
>
> Scott
--------------------------------------------------------------------------------------------------------------
Scott, like I said, I do this every day and never mess with
%#functions EVER. For example, I just now took a GUI, pushed the
pushbutton tool icon and dragged out a button on the window. Then I
clicked the disk icon to save the new .fig file. When I did that, it
placed this function into my m-file:

% --- Executes on button press in pushbutton11.
function pushbutton11_Callback(hObject, eventdata, handles)
% hObject handle to pushbutton11 (see GCBO)
% eventdata reserved - to be defined in a future version of MATLAB
% handles structure with handles and user data (see GUIDATA)

Now all I have to do is to start typing my code into that. When it
comes time to compile, I use the mcc command and it's fine. No
%#function needed anywhere in anything I do - GUIDE, property
Inspector, m-file, compiling, deploytool, nowhere, nowhere at all.
I'm not sure what you're talking about. Are you talking about the
"Callback" property in the Property Inspector? Do you want to, for
some reason, put in a call to a different function into the arg list
of the callback function listed there? You said:

3. Use GUIDE to modify the button callback property to specify the
function 'handle_button', which is contained in a separate m-file
handle_button.m

I'm saying "DON'T DO THAT!" Leave it alone. Skip that step! Like I
said, just type your code into the regular old familiar function that
it makes in your m-file. Don't mess with the Callback property in
GUIDE - it could lead to trouble - just let it use the default stuff
it creates for you in that property field. The only reason I can
think of at all that you would need it is if you put a function name
in a hard-coded string being passes to eval(), like Steve already
mentioned.
ImageAnalyst