In App Designed app: When does a function called within another function spawn a new thread?

Hi @Gavin,

You mentioned, “I'm having SO much trouble! I think maybe when I call a function from within another function or callback it's going into a new thread. I want it to finish the function before moving on. Is the best way to do that to make the function return a (dummy) value?Since there is nothing to return but completion do I need to declare”

Please see my response to your comments below.

In MATLAB, when you call a function from within another function or a callback, it does not automatically create a new thread; however, the execution order can sometimes be confusing, especially with asynchronous callbacks. To ensure that the calling function waits for the called function to complete, you do not need to return a dummy value. You can simply define your function as follows:

function MyFunction(app)
  % Your code here
end

If you do not need to return any value, you can call it without assigning it to a variable:

MyFunction(app);

Now, if you want to suppress warnings about unused return values, you can use the %#ok comment as you suggested:

fin = MyFunction(app); %#ok

However, it is not necessary to declare a return variable if you do not intend to use it. Just make sure that your function completes its execution before moving on to the next line of code in the calling function.

Hope this helps.

Hi @Gavin,

To address your concerns about managing function execution order in MATLAB App Designer, it is essential to understand the nature of asynchronous programming and how MATLAB handles callbacks. You probably aware of when a callback (like PicoInput%) is triggered, it executes asynchronously. This means that if another event occurs while the first callback is still running, the second callback may begin execution, leading to overlapping processes. So, to prevent this overlap, it is crucial to implement a mechanism that make sure one callback completes before another starts.

Now to address your query regarding, “Using waitfor function which is typically used to halt execution until a specified condition is met. However, it seems that you encountered issues using waitfor with RunTrial, which does not return an output value. A better approach would be to use a flag or a state variable to indicate whether the function is currently executing. For instance:

     properties
         IsRunning = false;  % State variable
     end

     function RunTrial(app, trlNum)
         if app.IsRunning
             return;  % Exit if already running
         end
         app.IsRunning = true;  % Set running state
         % ... execute trial logic ...
         app.IsRunning = false;  % Reset state when done
     end

Also, setting the Interruptible property of UI components can help manage how callbacks interact. If you want to make sure that certain critical functions (like reading from USB) are not interrupted, make sure they have Interruptible set to off. However, be aware that this will mean other user interactions won't interrupt these critical processes. For non-critical callbacks that might be interrupted, consider using the BusyAction property set to queue, this will make sure that if you trigger another callback while one is executing, the new callback will wait until the current one finishes rather than canceling it.

I saw that you are using dbstack, that cal really help you trace where errors occur in your code. If you encounter an error like "Not enough input arguments", checking the call stack at that point can provide insights into what might be going wrong.

It is frustrating that Asynchronous programming can often lead to complex scenarios in GUI applications where user interactions are frequent. That is why implementing state management techniques (like flags) greatly simplify control flow. Also, I would recommend testing various configurations of the Interruptible and BusyAction properties through trial and error which may help you yield insights into their effects on application responsiveness.

Hope this helps.

Hi @Gavin,

In addition to comments provided by @Walter Robertson and @Mario Malic, asynchronous programming allows multiple processes to run concurrently. In MATLAB, when a callback (like reading from a USB device) is triggered, it does not block the execution of subsequent callbacks. This can lead to complications if multiple events occur before the first one has completed. Implementing state management through flags or state variables is crucial. This allows you to prevent concurrent executions of critical functions. The provided code snippet below demonstrates this well:

classdef MyApp
  properties
      IsRunning = false;  % State variable to track if the trial 
      is running
  end

    methods
        function RunTrial(app, trlNum)
            % Check if the trial is already running
            if app.IsRunning
                return;  % Exit if already running
            end

            app.IsRunning = true;  % Set running state

            % Execute trial logic here
            fprintf('Running trial number: %d\n', trlNum);
            pause(2);  % Simulate trial execution time

            app.IsRunning = false;  % Reset state when done
        end
    end
  end

This code checks whether a trial is already running before proceeding, thus preventing overlap.

Please see attached.

I would like @Mario Malic to provide his feedback based on the code snippet provided.