unpause from a uifigure

I'm used to using pause to run through a loop with plots and to pause until hitting return. Something like this:

for i = 1:100
    plot(1:i)
    pause
end

(Edit: to clarify, this is pressing return while focuse on the figure window)

Now however if the code launches a uifigure, it is unclear how to run the same code. Is there a way of programatically unpausing?

fig = uifigure;
ax = axes(fig)
for i = 1:100
    plot(ax,1:i)
    pause
end

I know I can use uiwait and uiresume but it is unclear why I can't get code to work that supports pause as well.

[dpb]

Interactively, the above works as expected (if you give focus to the command window, anyway).

But, if the uifigure is in an app designer app, you may not have a command window visible to focus to and in which to enter user input.

[Jim Hokanson]

ah sorry, yes I forgot to mention this is specifically for pressing return while focus is on the uifigure (I'll update to clarify)

I've been trying to play around with: com.mathworks.mde.cmdwin.CmdWin.getInstance

but I haven't had any luck yet ...

[dpb]

"...for pressing return while focus is on the uifigure"

That isn't going to work because keyboard input doesn't go to the figure. Unfortunately, the ButtonDownFcn callback is not triggered during a pause, either..

I don't know if you could conjure up a way to use a while...end loop instead of the pause with a callback function that broke out of it or not, you might have to have a drawnow inside a tight loop in order for callbacks to get processed...

[Jim Hokanson]

I'm fairly certain I can make the uiwait/uiresume approach but I just dislike that now that there is a second type of figure my traditional approach to plot cycling doesn't work.

I'll note if you click on a traditional figure, not the uifigure, and press return, execution advances past the pause.

For the uifigure, I set the KeyPressFcn, and I can listen for pressing return, but it is unclear how to programatically untrigger the pause.

I tried the following but it doesn't work:

h = com.mathworks.mde.cmdwin.CmdWin.getInstance;
h.grabFocus
robot.keyPress(java.awt.event.KeyEvent.VK_ENTER);
robot.keyRelease(java.awt.event.KeyEvent.VK_ENTER);

[dpb]

"if you click on a traditional figure, not the uifigure, and press return, execution advances past the pause"

Yes, but a uifigure ain't a regular old figure.

With the uifigure I think the uiwait is probably the only option.

One could file an enhancement request but I wouldn't hold out much hope for any change in behavior...

[Jim Hokanson]

That gets back to the crux of the question. Clearly they are different, is there a workaround? From my perspective this is something a casual user may try when trying to cycle through plots (at least this is someting I've taught my students for many years now). It seems like as an end-user you don't want to be thinking about which type of figure you are being shown and to do different code based on that figure type. I may create a "pause2" function that requires the figure as an input and then pauses or uiwaits based on the type, although then that requires ensuring the figure handle is easily accessible which is not the case for uifigures.

Regardless, thank you for looking this question over and commenting.

Answer 1

[Image Analyst]

I still don't understand the workflow. It sounds like you may have some existing figures (either old style figures or new style uifigures) on display somehow from some other process, and your user might click on some particular figure and then run your script to do stuff, including calling pause. Is that right so far? Or is your for loop code part of an app designer-built GUI? But it sounds like sometimes you programmatically create a new figure in your code and want to know how not to pause. Is that right?

"Now however if the code launches a uifigure, it is unclear how to run the same code. Is there a way of programatically unpausing?"

So if your code had a call to figure to create a figure, then you could just do

fig = uifigure;
ax = axes(fig)
for i = 1:100
    plot(ax,1:i)
end

Now if there were no existing figures open yet and then your code ran and the first call to plot() created a new figure, then you can use findobj to search for how many plots there are in existence before getting into your loop. Then if it's 2 or more, set a flag. In the loop check the flag for whether you should call pause or not.

[dpb]

I believe @Jim Hokanson is used to simply always calling pause in a loop creating plots simply as a way to keep them on the screen for observation before the user decides to go to the next -- and with a traditional figure, a keyboard keypress breaks the indefinite pause.

However, if the code is inside a uifigure, MATLAB doesn't trap the keypress if focus is not physically in the command window so the above doesn't function as it did previously and he's attempting to find a workaround that does behave the same way.

I don't believe at present there is a way to replicate that behavior.

[Jim Hokanson]

Sorry for the confusion. dpb is correct, the goal is simply to have a simple way of inspecting a figure before deciding to move on to the next figure. The "user" is the one creating the loop with the pause statement. I am simply providing a plot method in a class that does some rendering on a uifigure. I can update my code to listen for key presses, but it is unclear what my code should do when a "return" key press is detected. It seems pretty clear that there is no official way to replicate this behavior. I was hoping someone might know an unofficial way of replicating the behavior.

Alternatively, perhaps I've been doing the plot/pause loop wrong all of these years, and there is a better approach to use?

[dpb]

For the purpose, the traditional pause solution is certainly the logical way; I've used it on occasion for exactly the same purpose fairly frequently. For that situation, I don't see a better solution.

I haven't tried, but one of the key differences between uifigure and figure is that the 'HandleVisibility' property defaults to 'off' with uifigure instead to 'on'. Thus the uifigure never can become the current object and so functions that rely on gcf or gca can't accidentally change an app interface object.

I wonder if for the specific case setting it 'on' instead would then let the keyboard keypress work. It would be necessary to return it to its default state afterwards, of course.

User apps with an interface don't envision the use of keyboard input other than via text boxes or editable tables and the like so the particular usage probably wasn't ever considered as part of a design specification. For that use case, adding a control to Pause/Continue is probably what would be the recommended solution instead despite the added complexity.