how to send a variable from input field in app designer to a function that is working as a subfunction?

Hi! :)

I have a problem:

In my small software program that I am making, I want the user to input the pressure in appdesigner and the pressure has to be input from user as it varies between 10 bar to 600 and I cant use for example a dropdownlist in a function. But my problem is that I am using the variable pressure in a subfunction some places so I dont understand how I can send it from an input field in app designer to those subfunctions..?

Any good ideas.?

[Stephen23]

"I dont understand how I can send it from an input field in app designer to those subfunctions..? Any good ideas.?"

Pass it as an input argument. Which in general is the simplest and most robust way to pass data to a function.

What exactly is stopping you from providing the data as an input when calling the function?

See also:

https://www.mathworks.com/help/matlab/matlab_prog/share-data-between-workspaces.html

https://www.mathworks.com/help/matlab/creating_guis/share-data-across-callbacks-in-app-designer.html

and for lots more advice related to creating apps using App designer:

https://www.mathworks.com/help/matlab/app-designer.html

[Cris LaPierre]

You may be thinking about this the wrong way. Are you wanting to have something happen when the user changes the pressure? Of does the function just need to access the current value whenever it is run?

If the former, you create a callback function for the input field. When the value is changed, it triggers the callback function to run. that function should run or call whatever code needs to execute.

If the latter, make sure all your functions accept the app object as input. Then you can access any property of the app, including the value of an app componenet (edit field, slider, etc)

[dpb]

"If the latter, make sure all your functions accept the app object as input. Then you can access any property of the app, including the value of an app componenet (edit field, slider, etc)"

If you create a set of properties for the values of the input variable(s), then the callback can be as simple as just storing the value the user inputs there and then the other computation functions can simply use that value which will be part of the app sturct/object.

A secondary advantage of this style is that a shutdown function can call a SaveState routine which can easily then write the various control values to a .mat file which the startup function can read when the app is restarted and the user will be able to resume from the identical spot left off last time used your app.

[Muazma Ali]

@Stephen23 I think I didnt manage to explain the problem in the right way:

In the app designer I am only calling one type of functions and those functions call another function that again calls another function that make use of the variable called pressure . In other words, the use of the variable pressure is "hidden" for the app designer. And that is the problem

[Stephen23]

"I am only calling one type of functions and those functions call another function that again calls another function that make use of the variable called pressure"

If all of those functions are part of the app then they can all access properties of that app.

If they are external to the app then define "pressure" as an input argument to each function.

[dpb]

If the functions need anything more than just the pressure, then all of those will have to be in the argument list(s). Hence the recommendation to just pass the app argument and have it contain all the needed parameters.

[Muazma Ali]

@dpb that was difficult for me to understand: what do you mean by argument list..?

[dpb]

The set (one or more) of values you need to pass to call a function

function res=myfunction(a, b, c)
  res=somefunction(a,b,c);
end

Here, a, b, c are the arguments; collectively, they are the argument list.

If in your app your function(s) were to need multiple arguments besides just the one pressure you mentioned, the argument list can get long and if there's a need to change the agruments in some function later on, you have to correct both the function and the caller to match. On the other hand, with an AppBuilder app, if you were to pass the app object, then you can make all the adjustments inside it and reference anything needed directly; the argument list to the function and calling it don't need to change.