Multiwindow app skips startup function

I am working on developing a GUI I inherited from someone else, and am running into a problem. When the GUI pulls up the second window, there are steps in the startupfcn that need to be run, most importantly, mapping the app to app.CallingApp. However, when run from the original GUI it never runs the startup function.

I tried going into debugging, and it goes all the way to graphicsCallbackProxy.m Line 22 in sync with the multiwindow app example on mathworks website. But at that point, the example then runs the startup fxn and my code skips it.

I then created a very simple multiwindow app. the first has a button that opens the second. When I run this GUI, the startup App is correctly run. When I call the popup window in my main code, the startup fcn is once again left unrun.

Code from the main script (Does not trigger the startup fxn below)

function STARTRECORDINGButtonValueChanged(app, event)
     
            value = app.STARTRECORDINGButton.Value;
            if value == 1
                app.log.markNum = 0;
                app.TagApp=testGUI(app);
                if app.err % app.err=13, insufficient disc space for file creation
                    stopStreamRec(app);
                end
                
            elseif value == 0
                exitLoopStopAcq(app);
            end
        end

Code from the test popup window

function startupFcn(app, mainApp)
            app.CallBack=mainApp;
            disp("test 123")
            disp(num2str( app.CallBack.x))
        end        

testing main function, triggers the running of the startup fxn above.

% Value changed function: Button
        function ButtonValueChanged(app, event)
            value = app.Button.Value;
            app.x=1:100;
            app.y=sin(app.x);
            app.TagApp=testGUI(app);
        end        

It's worth noting, there is no error tied to the startup fxn not running, only downstream from function calls to the original app, that don't work because the CallingApp was never defined because the startup fxn didn't run. I'm not sure if this matters, but the GUI trying to call a popup is the second window opened, the first window asks for save information, all of which is succesfully passed into the Main GUI.

Has anyone encountered this before, or see what may be causing the issue?

[Adam Danz]

> I tried going into debugging...

I'm assuming you tried placing a breakpoint at the first line of the startup fcn in the app that apparently is skipping the startup fcn and that breakpoint is never hit. If not, do that.

Is this the line that's calling the 2nd app? app.CallBack=mainApp;

If so, are you overwriting the "app" variable if that's even possible?

[Nicholas]

" I'm assuming you tried placing a breakpoint at the first line of the startup fcn in the app that apparently is skipping the startup fcn and that breakpoint is never hit. If not, do that. "

Yep, sure have, with 12 years experiencing debugging MATLAB code, breakpoints were the first thing I did. It never enters the startup fxn. As I mentioned above, I used step in command from the call to the second GUI, in the main funciton and this example from MATHWORKS https://www.mathworks.com/help/matlab/creating_guis/creating-multiwindow-apps-in-app-designer.html?searchHighlight=multiwindow&s_tid=srchtitle. and they perfectly follow each other, until the mathworks version enters the startupfxn and my version does not. I have no clue what prompts that because follwoing it step by step there was no switch, or if, or any other call to decide to enter the startup fxn, they exited the current fxn they were running and the mathworks moved into the startupfxn and my script did not.

"Is this the line that's calling the 2nd app? app.CallBack=mainApp"

no, that is the line in the second app startup fxn that copies the original app so it's fxns can be called, I used the multiwindow app tutorial to set that up and it works fine in the test case.

app.TagApp=testGUI(app);

that is the line that calls the second app. In the example in the first code block, it never enters the startup fxn, in the code in the third code block it will run the startup, and the gui it calls never changes.

[Adam Danz]

I see. What release of Matlab are you using?

What is graphicsCallbackProxy.m? That file doesn't exist in my r2020b intallation and doesn't appear in the forum or the documentation.

If you attach a zip file containing the files and briefly describe how to reproduce the problem on our ends, it would be helpful to explore. Otherwise, I wonder what the dbstack shows at the point where your debugging differs from what's expected.

[Nicholas]

I am running r2020a. I am fairly confident this function is a file created by mathworks. It is about 3 functions deep into the backend of app designer, and is present when using MATLAB online to step through the exact same process for their multi-window app example code. I was mistaken though, it actually steps out of that function this is the process that it follows.

call to new GUI occurs

• Appbase.m runs its startupFcn, function
• Appbase lines 42 and 43 are run
• Appbase line 43 then steps into AppManagementServcies.M lines 156 and 157,
• AppManagementServices.m line 157 calls into GraphisCallbackProxy lines 22 and 23
• It steps back up to AppManagementServices.m lines 360-366

That is where the bifurcation happens. The example runs the callback(app) function, my GUI enters the try loop and then immediately exits it without doing anything. Call_stack_test is the functionstack for the matlab example, call_stack_main is for my GUI.

I would zip and send you the GUI if I thought you would be able to run it, but this is for an image acquisition system, and is designed so that if it isn't getting synch signals from all 4 maxed out A/D converters it doesn't let the user continue trying to collect data.

[Adam Danz]

> my GUI enters the try loop and then immediately exits it without doing anything

Does that mean an error within the try-block within AppManagementService > tryCallback (line 359) evokes the catch-block? If so, when you place a breakpoint right at the first line within the catch-block, what does the exception say? If the try-block is fully executed without evoking the catch-block, does that mean that one of the callback() functions within the conditional statement is executed but has no perceivavble result? If that's the case, what function handles is stored in callback and what are the inputs (app and event)?

[Nicholas]

No, that was the weird part, it stepped into the try block, then stepped out without doing anything. If it had stepped into something I could have tried figuring out what was going wrong, but I couldn't explain how it was exiting the try block without doing anything.

I just spent the past day and a half rebuilding the GUI that everything is called out of and it resolved the issue. I'm not sure what the underlying cause was but a complete rebuild of the App that wasn't initiating the calls to startupfcns properly was a solution, albeit tediuous one.

Thanks for all your assistance! Have a wonderful day!