How can I work around the fact that app designer does not support output arguments?

I understand that the app designer does not permit output arguments. I am trying to work around that limitation. Some things I've tried include:

1. I have tried to add properties/app data/etc., but found that the app handle gets deleted when the GUI is exited. One solution would be if there is a way to prevent the handle being deleted so the added app data stays accessible. I spent a long time fruitlessly trying to trace that down.
2. Another way that would conceptually work would be to assignin to caller, but there are many levels of matlab inbuilt functions between the 'real' caller and the various callbacks and functions of the app. If there was a way to assign to a great great great Nth degree grandparent workspace, that would work, but I couldn't figure out how to assignin to anything other than 'base' or direct 'caller'. Similarly, I could assignin to base, but then I need to figure out how to get the data back down to the workspace that instantiated the app.
3. I could simply save the data and load it later, but how do I trigger the calling function to load the data when it's available? I can manually add commands to check for and load data everywhere I use the app, but I'm not the only one that is likely to use this code and added complications make for mistakes.
4. If I could setup some kind of listener at the 'real' caller level that could update that workspace, that might work too, but I'm not sure how to do that (or if it's possible given matlab's architecture)

The real driver of this is that I have various functions that are GUIs that are called by other functions (or even other GUIs) and I need to be able to pass data back to whatever called the data gathering GUI in the first place. Any ideas would be greatly appreciated!

Edit: Also... If I'm missing something and overcomplicating this, feel free to let me know what I'm missing. I hate to waste a bunch of time doing something inefficiently if there's an already tried and true simple way. I just want to be able to pop-up a customized GUI from within a function or higher level GUI, and get data from user interaction with images and video back to the calling function. (e.g. pops up live video and asks user to orient something and capture still, then confirm that still is subjectively suitable for purpose (or capture new still), then select points in still, and return points to caller)

Answer 1

[Stephen23]

Create a function which has two ways of being called:

1. as a wrapper for the app itself, passing any input arguments, etc.
2. as a callback, which stores whatever values you need using persistent or some nested function.

Set the function to be the DeleteFcn callback, when you can store the values you want.

Call the wrapper, which calls the app, use uiwait. The callback is triggered grab the values, which are then stored. uiwait resumes at that point, so you can return the values.

[Sean Cooper]

Hello Stephen,

Thanks for responding. I'm processing your answer and hopefully you can confirm my understanding.

It sounds like you are suggesting something like setting up a pair of classes, where:

• An object of class A is instantiated.
• During instantiation of class A, it calls the GUI in class B,
• When the GUI (class B) is done, it calls a method from the class A object in it's DeleteFcn callback to pass data back to the class A object.
• The class A object method populates a property in the class A object with the data.
• The function knows that the GUI is completed and has produced the necessary data when the data in the obj.property has changed from the default empty value.

Is that an accurate description of your suggestion?

Thanks

[Stephen23]

@Sean Cooper : well, I was thinking of actual MATLAB functions, but really it makes no difference: the key is to define the DeleteFcn to save the required values in some object/variable/whatever you prefer, after which the GUI closes (I guess a delete will also be required).

[Sean Cooper]

Stephen,

Thanks for the idea. While I'm not sure how I would implement this as a function, the classdef /object version seems to work exactly as I hoped, with the only drawback of having to distribute the effect across two files.

(i.e.

1. the first class is a handle subclass that spawns the second (which contains the GUI, and has the first class object as an input property), and holds the app handle and a placeholder for the desired data in properties. It returns a handle object to the calling workspace.
2. Execution in the main app can continue on other tasks while waiting for the data to be returned, while the human operator interacts with the GUI.
3. When the human is done, the GUI DeleteFcn main app can put the desired data in the data property of the original handle object returned by the first class using the handle object that was supplied at instantiation (and the calling function can determine at any time if that data is available by examining the handle object data property)

I don't think I would have thought of that solution without a lot of trial and error and beating my head against walls.

I was struggling to figure out how to get around the fact that the only output of apps from the app designer is a handle that self destructs on closing, and this circumvents that.

Thanks!

[George Pavlath]

Hard to understand how to implement this. A simple code example would be very helpful.

Answer 2

[Mark Thomson]

Dear All,

I also had the situation of wanting to use an App as an intermediate user interface to tailor and return parameters, called within a running function.

Here is a simple example that seems to work fine, similar to the suggestion above:

In the running function:

app_routine='test_external_call_with_output1';
app=feval(app_routine)
waitfor(app.FinishButton,'UserData')
output=app.output
app.delete

and in the App:

        function FinishButtonPushed(app, event)
            app.output=rand(3,4); % Just to demonstrate...
            app.FinishButton.UserData=1;
        end

where .output was a public property:

    properties (Access = public)
        output % Description
    end

Maybe there is a cleaner way than than this use waitfor and setting .UserData (e.g. with uiwait?). But I don't see any major problem suspending a running function and getting outputs from an App before continuing the function.

Regards, MT

[George Pavlath]

Thank you for your input. I have tried the technique that you proposed. It errors out at the step: app.output=

The error message is Unrecognized property 'output' for class 'outputTest'.

outputTest is the name of the app. I think the issue is the lack of the third part of your suggestion that declares the output property. It is unclear to me how to add this to the app code using appdesigner. Perhaps with this added to the app code it would work. Any suggestions?

[George Pavlath]

I figured out how to add the property output to the app as your third code block described. I now get a different error: Cannot access method 'FinishButtonPushed' in class 'outputTest'.

Looking in the methods section of the appdesigner in code view, I see that all methods are set to private. The appdesigner doesn't let me change the methods access to public. I have tried opening the app in the editor but that always opens up the app in appdesigner, where I cannot change the access to public for methods.

Any suggestions?

[George Pavlath]

Finally got it to run. This works! Great suggestion!

[Will Reeves]

Hi, Thanks for the suggestion, works well!. Is there any chance of implementing something more elegant from the Mathworks side though? Being able to assign outputs, in a similar way inputs are created, from the App designer would be nice.

Answer 3

[Adam Danz]

"I have various functions that are GUIs that are called by other functions (or even other GUIs) and I need to be able to pass data back to whatever called the data gathering GUI in the first place."

If your GUI was created with GUIDE or with uicontrol(), you can get outputs from the GUI but not in app designer. It's nice when GUIs are self-contained or only rely on built-in functions so that only the GUI file is needed to run the GUI in matlab. But if you have other functions or scripts that rely on a particular function, that function should be accessible outside of a GUI file. So, one solution would be to move the commonly used local function from the GUI to an external, independent function file. Afterall, GUI's are meant to be used by humans (or well trained non-human primates), not by other functions. So redesigning the flow of your code is probably the best solution.

In response to your listed options,

1) Forget about using the app structure outside of the app. There's no reason to save a bunch of graphics handles just to extract some embedded data. Besides, saving graphics handles can cause very large files and often times when you load the handle structure, it opens an additional instance of the GUI figure which is a nuisance.

2) Using assignin() or any of its friends causes more problems that what you started with. As you've correctly identified, this would be a cumbersome solution. Here's more background on why this is bad [link].

3a) "I could simply save the data and load it later"; If you can't move the local GUI functions to an external, independent function file, this may be a viable solution but it comes with more problems. The GUI can detect when it's been activated by a function rather than manually by a user. If it was activated by a function it could gather the needed outputs in a neat, tidy format and save it to a mat file. However, ...

3b) "but how do I trigger the calling function to load the data when it's available?" ...this is where things get complicated and ugly. I can imagine solutions for this problem but they all look like crumbling scaffolding around a demolished building in my imagination. For example, just before you call the GUI you could create an invisible graphics object. Just after calling the GUI you could add a while-loop that continually runs as long as the invisible graphics object exists (ishghandle). From within the GUI, when it's finished it searches for and deletes the inivisble graphics object which triggers the end of the while loop. Then the code can load the mat file into the function. This is a bad idea for so many reasons. What is the name of the file? Where does it exist? What if there's an error in the GUI and the while-loop runs for infinity? Why does a function need to run a GUI in the first place?

4) I don't see a big difference between this idea and idea #2.

[Sean Cooper]

Thanks for responding.

I agree that GUIs are meant to be used by humans. The disconnect seems to be that you seem to expect GUIs to be stand-alone programs that don't need to interact with anything else. I tend to use GUIs as ways to manage process control of complex analyses that have not-yet-sufficiently-automated analysis and/or dynamic data gathering steps and may (or may not) require human intervention, sometimes by me, but often by less technical (and definitely less matlab savvy) coworkers.

As such, my GUIs tend to be spawned to facilitate a specific human override of an otherwise automated analysis or decision point in a process, therefore the GUI is spawned as directed by the executing function and needs to return the critical decision data to that function.

In addition, I am not developing in a vacuum and there are other engineers (hardware-oriented quality and process engineers) that may need to build functions and scripts with the various building blocks I produce, so simple syntactical behavior is valuable.

I agree that, even specific implementations aside, use of anything like assignin() (including my listener function idea) is an architectural risk, although if it were efficient and could be encapsulated and verified, it would be acceptable.

With regard to saving the data... The name and location of the data is trivial, as it would be provided by the calling function, but how to trigger the caller to go get it without opening up a can of ugliness is a problem I don't have a solution to. It would make life much easier if I the exit/delete function callbacks could access top-level output arguments for the GUI (but alas I have seen no way to make that happen).

[Adam Danz]

Hi Sean,

"The disconnect seems to be that you seem to expect GUIs to be stand-alone programs that don't need to interact with anything else."

Kind of the opposite, actually. IMHO, GUIs can certainly interact with other programs (and even other GUIs when necessary). It potentially gets messy when a automated script or function outside of a GUI needs to interact with a GUI.

"As such, my GUIs tend to be spawned to facilitate a specific human override of an otherwise automated analysis or decision point in a process, therefore the GUI is spawned as directed by the executing function and needs to return the critical decision data to that function."

If the GUI is spawned by an external function so that there can be human interaction, then the external function must wait for a human-made response from the GUI. If this is your case there is a simple solution. Once the human interaction is complete the user presses a 'continue' button which contains a callback function that gathers the data and sends it back to the external function. This is a common workflow. What I understood in your question is that you'd like an external function to call a GUI and get output in an automated fashion that does not require human interaction. In that case there's no need for a user-interface in the first place which is why I suggested making those dependent functions external from the GUI.

"With regard to saving the data... The name and location of the data is trivial, as it would be provided by the calling function, but how to trigger the caller to go get it without opening up a can of ugliness is a problem I don't have a solution to."

I have a suggestion that I have used myself several times in similar circumstances. When the external function is called, it detects whether a filename is present in the inputs. If it is not present, the function calls upon the GUI and then terminates. The GUI detects that it was called automatically (not by a human), does whatever processing is needed, and creates the output filename which is sent back into the external function as an input. This time the external function detects that a filename is present and therefore skips the initial GUI process and jumps right to the next stage of analysis that acts on the file. This method is clean, easy to write and read, and doesn't require assignin() or any behind-the-scenes magic with invisible objects that acts as flags. I'd be glad to get into more detail if needed.