Calling a function defined in a m-file from within appdesigner app, with the app object as function input

I'm using R2019b.

I have created a GUI app using appdesigner and have written the function testFun in a m-file (testFun should also be usable by a non GUI approach, hence the m-file).

Within the app, I have declared a public property called someData:

properties (Access = public)
    someData = '';
end

From within the GUI app, testFun is called with app as a function argument:

testFun(app)

testFun is defined as follows:

function testFun(inputData)
    inputData.someData = 'hello world';
end

As you can see, there are no output arguments defined in testFun.

Yet when I run the app like this, the someData property gets the value 'hello world'.

How can this behavior be explained?

Answer 1

[Rik]

Your GUI (like all AppDesigner GUIs) has a pass-by-reference behavior (so it behaves like a handle class). That means the line you show modifies the original object, instead of creating a new one when the function is called.

You could create a GUI that doesn't work this way by using the normal figure class, so what is generally meant by a 'programmatic GUI', or GUIs created with GUIDE. For an overview of your options for GUI design, see this. For more information about pass-by-reference vs pass-by-value, see Comparison of handle and value classes in the documentation.

[Guillaume]

See Comparison of handle and value classes in the documentation. All Apps are handle classes. Handle classes behave differently from traditional matlab objects such as matrices.

[Rik]

That was my guess, but searching for the documentation page that explains it on mobile was a bit tricky. Thanks for the link, I'll edit my answer.

[Lucademicus]

Thank you for the effort and documentation Rik and Guillaume!

[Guillaume]

You could create a GUI that doesn't work this way by using the normal figure class

The App designer is so much better than any of the other tools that I wouldn't recommend switching away from it. It's far from perfect but for beginners it's the best tool available. I would certainly not switch to GUIDE which is now more or less deprecated.

In any case, whichever designer you use, you're always going to end up passing handles of your GUI around. If you were passing value objects, then every time you pass the GUI object, you'd be creating a copy of the GUI including the figure window. By necessity, it must be a handle.

[Lucademicus]

The previous GUI I made (and is still under development) is built programatically. The benefit of this, is that it can be kept within version control with Git. This is not possible with appdesigner, as the mlapp-file is a (binary) archive. I regard this as a shortcoming, I guess the only way to get around this is to do the designing within appdesigner and export it to a m-file every now and then.

[Guillaume]

A mlapp is a zip file that contains mostly text text files, so you could unzip the app/rezip the app as a pre/post commit task but yes I agree that for version control it's not ideal. As I said, it's far from perfect. In term of coding pattern, it's much better than GUIDE.

What I'd really like is something akin to the Visual Studio designer in .Net where you get just two (text) files: your class code (initialiser and callbacks) and the designer code (which you can edit if you know what you're doing).

[Lucademicus]

Alternatively I could create a little shell script which unzips myGUI.mlapp to myGUI/ everytime the mlapp-file is modified. This fits more readily in my Git workflow. Then I can keep the myGUI/ folder and the mlapp-file both within versioning. Any thoughts on this?

[Rik]

I don't know what the designer code equivalent would be in Matlab, but you could make a programmatic GUI based on a class instead of functions. That way you would have a text file for Git to work with.

But I'm not sure if that actually solves the issue, since you leave the AppDesigner to do this.