Restarting background data acquisition when going back - multiple mlapp files

App designer app with multiple files. Each screen is being opened by the previous screen, then hiding the previous screen.

Each screen is displaying different data, at different rates (and thus needs it's own ScansAvailableFcn).

No issues starting background data acquisition when entering the next screen - but when you click back to go to the previous screen (and delete current screen) I have not found any good way to re-start background data acquisition with the previous screens ScansAvailableFcn.

Currently using a flag variable and just watching to see the next screen closed inside my "Continue Button Pushed" callback - but that seems wasteful and silly. Feels like there has to be a better way other than just looping and pausing while waiting for the next screen to disappear.

Code Example -

Screen2.mlapp

function ContinueButtonPushed(app, event)
%First, stop the DAQ
stop(app.DAQ)
%Set Next screen open variable
app.SC3Open=1;          
%Start new screen
screen3(app,app.UIFigure.Position);
%Monitor open screen fopr close      
while (app.SC3Open>0)
    % The next screen exists
    pause(1);
end           
%Screen gone - Start the DAQ with this screen settings
DAQStart(app);
end

Screen3.mlapp

function BackButtonPushed(app, event) 
%First, stop the DAQ
stop(app.Screen2.DAQ)
%Set Screen Open variable to show closed
app.Screen2.SC3Open = 0;
%Make previous screen visible and delete current screen
app.Screen2.UIFigure.Visible = 'on';
drawnow;
delete(app);
end

[dpb]

If the DAQ is beinig stopped from one step to another, why is it necessary to compound issues by having several chained apps; why can't simply set a new figure for the specific data and then restart the DAQ with its new set of conditions? It seems overly complex scheme this way...

[Aaron Borgman]

I'm not really sure what you mean, or if that is an option.

This code is largely based off "Create Multiwindow Apps in App Designer" ( https://www.mathworks.com/help/matlab/creating_guis/creating-multiwindow-apps-in-app-designer.html )

I need there to be several step by step windows. They need to display different data, and take different inputs from the user (every window is a UI, not just a plot or display. Every window needs to be able to refer to user input from previous windows. User input in previous windows need to be persistent when you go back to the window.

I can't see that there is any way to creat multiple uifigures inside a single app in App Designer.

[Aaron Borgman]

https://www.mathworks.com/matlabcentral/answers/1953859-how-to-create-multiple-uifigures-in-appdesigner

and

https://www.mathworks.com/matlabcentral/answers/1802235-how-to-add-a-new-uifigure-in-app-designer

Seem to indicate it can't be done.

[dpb]

My bad...I wrote figure when was thinking about multiple panes/axes, sorry. If one needs a whole different UI and not just what data is acquired/displayed, then it's a problem, granted.

It would seem the idea would be that the various higher level apps need to pass their app struct from the parent to the child on creation. In that case, create the OnRestart function in each parent app as a Public function and pass its handle to the child app. The child can then execute that function in its BackButton callback before exiting.

Just thinking off the cuff, that routine might be a one-shot timer whose callback is to check a "WakeUp" variable also set by the exiting child process on exit. That would eliminate the need for a polling operation and provide a little delay time for the context switching to occur.

Answer 1

[Stephen23]

dpb has the right idea. Using an explicit polling loop (while/pause) to watch for the closure of the child screen adds unnecessary CPU burden and usage. It’s not idiomatic for event-driven GUIs and can introduce lag or odd behaviors. You can probably adopt a callback/event mechanism to notify the parent screen when the child closes. This avoids polling and is much more robust.

Solution Outline:

1. Use Function Handles/CallbacksWhen creating the child app from the parent, pass in a handle to a function in the parent which the child can call on exit.
2. On Back/Exit:The child executes this callback before it deletes itself, triggering immediate action in the parent app (e.g., restarting DAQ, updating UI).

Something like this (untested):

% In ParentFigure.mlapp
methods (Access = public)
    function restartDAQ(app)
        DAQStart(app);
        % Additional UI updates if needed
    end
end

% When launching the child figure:
ChildFigure(app, @(varargin) app.restartDAQ());

% In ChildFigure.mlapp
properties (Access = public)
    CloseCallback
end

% In constructor:
function ChildFigure(parentApp, closeCallback)
    app.CloseCallback = closeCallback;
    % ... other init ...
end

% In child Back button callback:
function BackButtonPushed(app, event)
    stop(app.ParentFigure.DAQ);
    if ~isempty(app.CloseCallback)
        app.CloseCallback();
    end
    app.ParentFigure.UIFigure.Visible = 'on';
    delete(app);
end

• No polling or pause loop needed.
• Parent screen is notified immediately.
• DAQ can be restarted cleanly, and any other UI updates can be made.
• More robust, scalable, and MATLAB-esque.

Don’t poll for screen closure: pass a callback function handle from parent to child, and have the child call it when you exit. This is an event-driven approach, fits the GUI paradigm, and makes your code cleaner and more maintainable.

[Aaron Borgman]

Thank You! This works perfectly - and was exactly what I was trying to do before polling, but just couldn't get to work.