Please explain inconsistent use of parameters within UI handle function calls.

In the code below, there are two UI calls which require function handles. 'fig' and 'myQuititem' are objects. In the fig.CloseRequestFcn call two parameter are passed along with the function handle just after the @ and the function definition below does not require a parameter list. In the myQuitItem.MenuSelectedFcn call, no parameters are passed after the @, but the function definition absolutely requires two parameters 'src' and 'event'. The is very confusing. Why the two different ways of passing parameters? What is different between these two methods? These are both nested functions and so the object 'fig' is available to both functions, but what if they were not nested? How would you pass the object fig to the functions?

[Christopher McKenzie]

[Christopher McKenzie]

Nevermind. I answered my own question.

In the case of fig.CloseRequestFcn, it expects a function handle and the function needs to have two inputs; a handle to the figure 'fig' and another input, in this case arbiraritly called 'event'. In this case it is set up as an anonymous function, but the function does not use the 'event' input and the 'fig handle' is availabe to the nested function call. However, it could have been set up like a regular anonymous function like this:

"fig.CoseRequestFcn = @(fig,event)my_closereq(fig,event);

...

function my_closereq(passedfig, passedevent)"

and that would work.

Or it could have been just a pure function handle:

"fig.CoseRequestFcn = @my_closereq;

...

function my_closereq(passedfig, passedevent)"

and that works too.

The advantage of the first way is that you can create functions with extra inputs:

"myQuitItem.MenuSelectedFcn = @(src,event)quitThisWindow(src,event,fig);

...

function quitThisWindow(passedsrc,passedevent,passedfig)"

I can now pass on the 'fig' handle without the need to make it global or assuming the functions are nested.

[Tommy]

If you are interested, another way to pass extra parameters without using an anonymous function is

myQuitItem.MenuSelectedFcn = {@quitThisWindow,fig};

[Christopher McKenzie]

OK. So that's what they were talking about in some of the descriptions. I assume the function would still be defined as:

function quitThisWindow(passedsrc,passedevent,passedfig)

What I also find intersting is that while functions like uifigure() return the handle to an object, they are in fact not classes, so you can't do this:

methods uifigure

Even though fig.CloseRequestFcn acts just like a method.

[Christopher McKenzie]

Oh. Nevermind. I see, ClostRequestFcn is really a property not a method. So while uifigure is just a function call it returns an object with certain properties. I think.

[Tommy]

You're right about the function definition. And I think you've also got the right idea with your second comment. CloseRequestFcn is a property of a figure object which you are setting equal to some method in the methods block.

[Christopher McKenzie]

Thanks for the help Tommy. This item has been answered.

[Steven Lord]

While

methods uifigure

won't work because as you said uifigure is a function that returns an object not a class itself, methods can accept an object as input and will return the methods of the class of that object.

methods(uifigure)

The command form passes the text 'uifigure' into methods while the function form passes the object returned by calling uifigure into methods.