Can I have more than one input variable in my startupfunction for an app?

Hi ! :)

I am not attaching any files this time because it is a little complicated as I have a multiwindow app including many apps with their corresponding functions.

But I will try to specify my question in a clear way:

I have an app called Monte Carlo which is called from app2.

The vector called osmotic_skew that is used in Monte Carlo to make a historgram, is calculated in app3, in app3 I have also declared it as public as I am using it in MonteCarlo.

I have problems in understanding how I can use the vector in MonteCarlo app: I have written :

histogram(app.UIAxes,app.Callingapp.osmotic_B_skew,50)  

But it is wrong as the the vector osmotic_B_skew is calculated in app3 hence is not from Callingapp.

Thats probably why I am getting an error saying the vector is empty.

My question in then : Can I have more than one input variable in MonteCarlo startup function or how else can my problem be solved?

Thanks for taking time to look on my problem!

[Cris LaPierre]

Have you seen this example? Share Data in Multiwindow Apps

[dpb]

"...the vector osmotic_B_skew is calculated in app3 hence is not from Callingapp."

The issue may simply be one of design and deciding who is in charge of the whole thing, as to how to control execution of app3 to compute the resulting vector. If it has an independent set of UI components to set the input parameters, then you could have the MonteCarlo app call the public callback function to compute and return the vector when needed where it would have access to the current local parameters.

Maybe rethinking the overall program flow could simplify things although the link to the sample app and related doc can show you alternate techniques.

[Muazma Ali]

Sorry, I think it would be complicated for me to think of redesigning my app and the document that somebody here has shared, gives insight in simpler problem than I have, I think..So I hope somebody can help me with my problem as it is...

[dpb]

Well, there's not much else anybody here can do without a much more complete description of the code structure and who is driving whom.

What's to prevent my suggestion of simply making the call public and having MonteCarlo call the other app that computes the vector and have it return it on demand?

Or, why does it have to reside in a different app; why doesn't MonteCarlo contain the pieces it needs to begin with? If it setting parameters externally, then the idea illustrated with the creation of the dialog would seem to be almost what you're looking at.

[Muazma Ali]

@dpb maybe I am not very good in Matlab but right now I am struggling to understand what you mean by " making the call public"..?

When you write "MonteCarlo call the other app that computes the vector and have it return it on demand?", it is difficult for me to understand how it can be done because app3 which computes that vector, is doing several other things..how can I make it return on demand..? can you illustrate it with a small example?

[dpb]

",,,what you mean by " making the call public"..?"

It's making the function you want to call externally Public so it can be seen from outside the App, and hence, called from your other application. The specific instruction is in the example multi-window app in th doc link @Cris LaPierre showed you. It's specifically at the top of the following page that's just a click or two in -- <Making a function call Public>

As that outlines, to be able to communicate between the two (or more) apps, your alternate windows/apps have to have startup function code that will save the app of each so they can be accessed. Read through that description carefully, where it has a dialog, think of your alternate app and substitute the vector you need to return for the properties there. It's a quite similar functionality, just named differently with slightly different components.

The problem is you've not provided the information on how these several applications are started and which of them is in charge. If you have built them all as totally independent being started separately by the user, that's a problem -- there then is no way with high-level MATLAB code to get any information about one of these processes from another; they're totally separate program spaces and "know nothink!" about each other.

However, one of the apps can call another just as any other m-file function; but those then also still need startup code and a way to share their local app data.

Answer 1

[dpb]

"[C]an you illustrate it with a small example?"

Attached are two blank apps, app1 and app2; the first that calls the second which exposes its internal app struct ('App2') in its startup function as the multi-window example illustrates.

The Public function MakeVector() which at the moment just returns a 20-element rand vector has also been added to it (app2).

app1 calls MakeVector() and draws a histogram. To illustrate, put both .mlapp files in your working directory and run app1...it'll show a couple of internal pieces disp()'ed at the command window and then the histogram. You'll have to stop the second figure with the X; I added no controls whatsoever to a blank app, just code to show how to call the function in the second from the first. You'll have to augment with all your controls and whatever else you need, but it's the idea of "how".

The guts of the idea without all the cruft to create the app is:

App1:

...
  properties (Access = public)
    App1                      % application app struct to be exposed
    App2                      % app2 returned app struct
  end

  % Callbacks that handle component events
  methods (Access = private)

    % Code that executes after component creation
    function startup(app)
      app.App1=app;                                 % save this app's app struct 
      disp('Hello from App1')
      app2(app.App1)                                % call the second passing this one's app
      vec=app.App2.MakeVector();                    % call the public function in second app
      histogram(vec)                                % and histogram it...
      pause(2)                                      % wait a second before quitting
      delete(app)                                   % kill self; could add to stop app2
    end
    end

You'll note the addition of the app struct of the calling app, app.App1, as an argument to the second app so it can see and expose its own app struct back (app.App2). You can see that by looking in the AppDesigner Design View at the figure properties.

app2

  classdef app2 < matlab.apps.AppBase

  % Properties that correspond to app components
  properties (Access = public)
    UIFigure  matlab.ui.Figure
  end

  
  properties (Access = public)
    App1                        % calling application app struct
    App2                        % application app struct to be exposed
  end
  
  methods (Access = public)
  % whatever the vector-creating function stuff you need function entry point
  function vec= MakeVector()    % add whatever arguments you need
      vec=rand(1,20)            % left off ; so can see is called at command window 
    end
  end
  

  % Callbacks that handle component events
  methods (Access = private)

    % Code that executes after component creation
    function startup(app, app1)
      % NOTA BENE the second argument which is the first/calling app's app struct
      app.App2=app;                     % save this app's struct 
      app.App1=app1;                    % and the caller's
      app.App1                          % just to show it was done
      disp('Hello from App2')
      % here's the key point-app2 struct stuffed into in app1 added properties so can find public objects/functions
      % since we're in app2, "app" belongs to it, but it will be "app.App2" in app1...where
      % "app" back in app1 is its local app struct to which added the App1 and App2 properties
      app1.App2=app;
    end
  end

You'll see for brevity I just put everything in the startup functions so it would run without needing user intervention to demonstrate the idea. For the real case, only the saving of the app structs so can be seen in other app is needed here; everything else can go into callbacks or purpose-driven public functions.

Creating and using meaningful names in place of "app1" and "app2" will help keep things straight as far as "who's who in the zoo"...I would recomend to make them recognizable but short as they'll be used a lot and it's simpler to read short, succinct code than long-winded variable names that don't really add anything but volume.