How do I call a function when the GUI has finished loading.

I have a working GUI app, based on a single screen.

To improve the usability, I wish to populate various UI tables and button options at startup. I have a function which will do this successfully.

However, I can only get this function to work as a result of clicking a configured button on the GUI.

I have tried to execute the function from startupFcn but I get errors... eg 'Reference to a cleared variable app'.

My assumption is that the GUI has not fully loaded ....

How can I trigger this function automatically at startup (rather than the error prone and ugly option for the user to press a button.).

I have spent days and days trying to find a solution but to no avail.

[dpb]

I've an app that reads/reloads existing GUI components from saved configuration previous execution for user convenience on next use that is called from the startup function and it has no trouble writing to the various GUI components.

Think would have to see the code and where the error is being generated and the message in context to have any idea what might be going wrong here, but your function as currently implemented seems to be trying to reference an object that is not in context or has been explcitly cleared previously.

One way that could be is that your data values to restore are referring to the .Value property of the component at the previous incarnation which will have been cleared and a new one created for the new invocation. To do this, you'll have to save the actual hard data values themselves to a file and reload from the data obtained by reading it on startup; anything from the previous incarnation is not accessible any longer--anything referenced to on the RHS with "app.XXXX" is probably no longer a valid reference.

[Matt O'Brien]

I am delighted with such a prompt response.

I will create a very simple gui to replicate my issue, using just a few lines of code and a few gui elements and post here (if I can).

[dpb]

You may actually find that doing that leads you to the solution of your other problem... :)

[Matt O'Brien]

I found the problem........

Self inflicted.

There was a 'clear' instruction as the first instruction in startupFcn. [A 'clear' example of self destruct....boom]

Not sure how or why it got there. It has been there for months .... but abandoned trying to solve this initial settings problem until I had everything else in good shape, then did not notice it when I returned to it. The 'clear' was probably typed in...... thinking I was typing into the command window.

I could see the set initial values principle with startupFcn working when I created a 10 line gui. Your answer gave me the encouragement that it should work....so thanks a bunch for your prompt reply ..... ....

[dpb]

clear is almost never needed and should be avoided like the plague until it really, really is needed. Can't have been more than a half-dozen times if that in 40 years using MATLAB it was actually needed other than just for cleaning up after an Answers session or something similar interactively.

The teaching paradigm that instructors use that is, I presume, from whence the abomination comes, is for their convenience only for grading homework on a consistent basis. It serves only the purpose there to ensure that what the student submits doesn't rely on something in the workspace beyond the actual code submitted.

Besides clearing variables, it kills cache and thus is a needless overhead almost always.

Functions have their own workspace on creation and all of those variables go out of scope automagically on exit so there's no point there at all just as a general practice. Once in a great while one may find it helpful to release memory of a no-longer-needed large array, but for the most part that's about the only time it should ever show up in either scripts or functions.

[Matt O'Brien]

Agree completely. Cannot understand why it was there. Had no reason to use it. Understand all the reasons why it should not be there. I lost days and days trying to find this bug.

[dpb]

It's often easy to overlook the [too patently] obvious looking for the bizarre...