MATLAB GUI hangs up despite using drawnow and pause

Hi everyone, I have a MATLAB GUI that looks as shown below:

What I am trying to achieve is that MATLAB keep checking for midnight continuously, except for the pauses when the user makes any change to the interface. Hence, I am running a while loop in the background continuously as I need to check if it is midnight. If it is, I perform some functions. The function that contains this while loop is called after any user input change is detected i.e. in all the callback functions for the pop-up menus,pushbuttons, textboxes etc. This is the reason I had the drawnow in the while loop, so that if the user makes any changes and wants to run some calculations, that will be detected. After the completion of the calculations, I again call the function which has this while loop.

The issue is, even though I use drawnow and pause in my while loop, sometimes, not always, MATLAB still hangs-up on me and the GUI becomes unresponsive and does not recognize any of the user inputs. Here is the while loop part of my code:

while 1
    pause(0.1);
    drawnow;
    pause(0.1);
    current_time=clock;
    if current_time(4)==0
        post_mortem;
    end
end

I know the above code is not efficient as it will call post_mortem continuously in the midnight hour, that however is not my issue right now. My issue is that it hangs up on me at times even at noon for example. Does anybody have any solution to this? On searching for answers to previous similar questions, the solution seemed to be to use drawnow and pause, but that doesn't seem to be working for me either.

Any guidance would be appreciated.

Thank you

Answer 1

[Walter Roberson]

The 4th element of clock is 0 for the entire hour from midnight to 1 am. Your code is going to call the post_mortem every 0.1 second for the entire hour.

You should be considering using a timer(). Or coding

current_time = clock;
last_hour = current_time(4);

while stop_timer==0
  pause(0.1);   %pause triggers draw as well
  current_time=clock;
  current_hour = current_time(4);
  if current_hour < last_hour    %corrected
      post_mortem;
  end
  last_hour = current_hour;
end

This code does not rely upon the time increment being 0.1 second: it only relies on the time increment being at most 23 hours (or perhaps 22:59.9999, I would need to think more about the exact boundary condition.). It considers midnight to have been crossed if the current hour is less than the hour at which we last checked -- so for example if your last check was 17:23 and your next check was 08:27 the next day, then it would be able to detect the midnight crossing.

[abc]

Thank you Walter. I don't expect this tool to be used anytime after regular working hours and so I didn't worry that it would be calling post_mortem throughout the midnight hour, although I agree that it can be avoided. However my issue is that even when its noon for example, and let's say the user is playing around with the GUI, it sometimes hangs up. Since the solution you provided, still runs in a continuous while loop, wouldn't it face the same issue?

Thank you.

[Walter Roberson]

I just realized the code should have

if current_hour < last_hour

rather than the other way around.

[abc]

Hi Walter,

Yes this is correct. However, will this change prevent hang-ups of the GUI during the rest of the day? Isn't it still a continuous while loop similar to what I had earlier?

[Walter Roberson]

I do not know what "regular working hours" is for where you are, but your code does nothing but wait every 0.1 seconds every hour except 00:00.00 to 00:59.59, and for 00:00 to 00:59.59 it runs post_mortem every 0.1 seconds. If "regular working hours" never includes the midnight hour, then the post_mortem would never be called, and if "regular working hours" does include the midnight hour, then it would indeed be called ever 0.1 seconds and so would be a problem.

Note: your code has no way of making stop_timer ~= 0, not unless post_mortem is doing an assignin('caller'), or unless stop_timer is a global that is set in post_mortem. So if the user does accidentally invoke the function, the user is going to be stuck there. If stop_timer is intended to represent the state of a pushbutton, you need to query it each time through the loop, such as

set(handles.NeedToStop, 'UserData', 0);
while get(handles.NeedToStop, 'UserData') == 0
  ...
end

with

function NeedToStop_Callback(src, event)
   set(src, 'UserData', 1);

[abc]

Hi Walter,

What I am trying to achieve is that MATLAB keep checking for midnight continuously, except for the pauses when the user makes any change to the interface. The function that contains this while loop is called after any user input change is detected i.e. in all the callback functions for the pop-up menus,pushbuttons, textboxes etc. This is the reason I had the drawnow in the while loop, so that if the user makes any changes and wants to run some calculations, that will be detected. After the completion of the calculations, I again call the function which has this while loop. Thus even if it is not midnight hour, it does enter the while loop and keeps checking for midnight. And on some occasions, not always, the interface hangs up.

[abc]

To further clarify the previous post, stop_timer is in fact a global variable. However, since I want to check the time continuously, it is not set to 1 (currently) in any part of my code. Hence, at present it is as good as

while 1 
...
end

[Walter Roberson]

https://www.mathworks.com/help/matlab/ref/drawnow.html#burd3gs-3

Actions Equivalent to drawnow

These actions are equivalent to calling a full drawnow command:

• Returning to the MATLAB® prompt.
• Using the figure, getframe, input, pause, and keyboard functions.
• Using functions that wait for user input, such as waitforbuttonpress, waitfor, or ginput.

[Walter Roberson]

I do not understand why you do not use a timer set for 24 hours:

n = now;
start_delay = (ceil(n) - n) * 24*60*60;
t = timer('ExecutionMode', 'FixedRate', 'Period', 24*60*60, 'StartDelay', start_delay, 'TimerFcn', @(src, event) post_mortem);
start(t);

Just make sure that t does not go out of scope.

[abc]

Thank you for your suggestion Walter. I used:

handles.mytimer = timer('ExecutionMode', 'FixedRate', ...
    'Period', 15*60, ...
    'BusyMode', 'drop', ...
    'TimerFcn', @(s,e)checktime());

and so far haven't seen any freezing issues.