Code runs when stepping in debugger, but when run normally I lose fields from handles structure

Edit:Made code variable names more clear

Using Matlab 2016a, on a 3gig ram machine

I'm developing a simple media player within a GUI using a timer and a few control buttons. The code was running videos as desired, so i set about adding my start/stop/pause buttons. These are simple and work as intended (when no video running) however since adding them i can no longer run videos properly.

The GUI stores data about the current frame and what direction playback is in in my handles structure, on each call of the timer I update the handles structure.

The problem i'm experiencing is that after one or two calls of the timer function I lose certain data fields within my handle structure stopping the player from working. I can't work out why this is happening, I call no other functions between the timer function calls, and the same code was previously working. When i came to debug this I found that there were no errors and in fact when stepping through the debugger the code actually works fine and there is no data loss.

The timer function is as follows:

{
function timerfunc(~,~,GUI_Figure_Handle)
handles = guidata(GUI_Figure_Handle);
handles.current_frame = handles.current_frame+handles.current_command;
if handles.current_frame ~= handles.no_frames
     imshow(handles.movie_data(handles.currrent_frame).cdata,'parent',handles.player;
     handles.text2.String = handles.current_frame*0.02;
     drawnow;
end
guidata(GUI_Figure_Handle,handles);
}

As I say the only thing I believe I've changed is adding some other functions none of which are called. I'm not losing all the fields of handles structure either, only a few that I'm setting after initializing the GUI. But not all of the lost variables are accessed by the timer.

Due to the code running when its operated step by step I'm unsure that my code is directly to blame and wonder if it could be to do with memory.

Any help would be much appreciated.

[Adam]

What is 'handles' that is being passed in to your function? This is a very odd name for what it appears to be. It clearly isn't the handles struct as you pass it to guidata and assign the result to something you call 'handle' so I am assuming 'handles' is the handle to your main GUI?

[Tom Pryke]

Yes it is the handle for the main GUI, apologies for the variable naming, i do intend to fix it. It was because I wanted to pass the handles strucuture from the GUI straight to the timer, but couldn't

Answer 1

[Steven Lord]

If you define the TimerFcn to accept handles, like:

% I assume handles exists in the workspace before this line of code executes
t = timer('TimerFcn', @(h, eventdata) myTimerFcn(h, eventdata, handles));

then the timer object (technically the anonymous function stored in the timer object as its TimerFcn property) stores a copy of the handles structure as it exists at the moment the TimerFcn is defined and changes to the handles structure afterwards will not be reflected in that copy.

If you want your TimerFcn to use the most up-to-date version of the handles structure, pass a handle to some part of your GUI that is unlikely to change (like the GUI figure itself) and use guidata inside the TimerFcn to retrieve the handles structure. See for example the first line of code in the update_display function in this documentation example.

[Tom Pryke]

I do define the timer object like that, however I'm afraid my variable names are unclear.

The variable 'handles' in 'function timerfunc(~,~,handles)' is the figure handle to the main GUI so when i call guidata I am getting the most up to date version of the handles structure associated with my main GUI.

[Steven Lord]

Do you lose data when the timer's TimerFcn executes while a callback function of one of the components in your GUI is executing? If so, I suspect you are running into a race condition where both the TimerFcn and the graphics component's Callback are trying to update the "master copy" of the handles structure using guidata on their own local copy. For example:

1. The graphics object's Callback starts and gets its local copy of the handles structure, call it handlesCall.
2. Then TimerFcn triggers and gets its copy, let's call it handlesTimer.
3. The TimerFcn finishes executing first and updates the master copy of the handles structure with handlesTimer. At this point handlesTimer and the master copy are in sync, but handlesCall has different information.
4. Finally the callback function finishes and overwrites the master copy with handlesCall, eliminating any changes made to handlesTimer. Now handlesCall and the master copy are in sync, but handlesTimer is different.

Note that you could interchange the Callback and the TimerFcn to end up with a final master copy that's in sync with handlesTimer but not handlesCall.

Does this accurately describe the scenario you're observing?

[Tom Pryke]

That sounds like what was happening, there were numerous functions updating the handles structure and they may well have got out of sync. Except that I wasn't just losing data i was losing whole fields, and none of my functions should do that, so I'm still unsure.

However I have since developed a different solution, instead of storing 'current data' (data I need to update the figure and what was being lost) in the handles structure directly rather I store them in userdata of the timer. Then I can access them more easily within Timerfcn, and this has fixed the problem i was experiencing.

Thank you for your help