how to use a (matrix) variable from one callback to another callback in GUI?

I load a cell from a .mat file and convert it to mat and save it in a variable called "MelisaW". Now, I want to use this MelisaW in another call back function lets say PopUpMenu. So How do I use it?

   function StartAnimation_Callback(hObject, eventdata, handles)
   % hObject    handle to StartAnimation (see GCBO)
   load('PMelisa01.mat', 'PMelisaD20180404Walkingnone01');
   MelisaW = cell2mat(PMelisaD20180404Walkingnone01);
   Plot(MelisaW(1,1),MelisaW(2,2));
   End

Another callback: want to access "MelisaW" in the cases of switch-case.

   function popupmenu1_Callback(hObject, eventdata, handles)
   % hObject    handle to popupmenu1 (see GCBO)
   ax2 = handles.axes2;
   str = get(hObject, 'String');
   val = get(hObject,'Value');
   switch str{val};
      case'head'
          for i=1:200
              PMelisaD20180404Head_Px=MelisaW(i,1)/100; %here i want to use that MelisaW
              plot(ax2,i,PMelisaD20180404Head_Px,'o');
    end

[Ameer Hamza]

You are loading mat file inside the callback function. Calling load() inside a function is unrecommended. Please refer to the link and below comments to get an idea of why is this the case. It might be easy to load variable in base workspace and then pass it to both callbacks as 4th argument.

[Stephen23]

"Calling load() inside a function is unrecommended. It is better to load variable in base workspace and then pass it to both callbacks as 4th argument."

Why is it not recommended to use load inside a callback? Can you show a reference for this? Or any threads where experienced MATLAB users state this? I don't see any reason why it is a bad idea to load data inside a callback: can you please explain any good reason for this advice?

[Ameer Hamza]

In one of your previous thread, while discussing dynamically naming variables you mentioned

"Note that all of these problems and disadvantages also apply to functions load (without an output variable)"

which is exactly the case here.

Also, every time the load() function is executed, there is an unnecessary overhead of loading the .mat file into memory. Additionally, since matrices are scoped objects there will be the additional overhead of cleaning it at the end of every callback execution. Both of these problems can be easily avoided by loading the data in the base workspace and then passing it to functions. Additionally, It can be noticed that both of the callback function given in the question are not modifying variable MelisaW at all, and thanks to cpy-on-write, both callbacks can share the same variable from base workspace (i.e. no copying required as compared to using load() in each callback execution).

[Stephen23]

"In one of your previous thread, while discussing dynamically naming variables you mentioned... which is exactly the case here."

That is exactly the case here... but in your original comment you did not mention this at all. Here is the complete text of your comment: "You are loading mat file inside the callback function. Calling load() inside a function is unrecommended. It is better to load variable in base workspace and then pass it to both callbacks as 4th argument." I don't see any mention of the words "output argument", nor any recommendation that load should be called with an output argument. Your original comment avoids this topic entirely (unlike my answer, which clearly shows load being used with an output argument).

"Additionally, since matrices are scoped objects there will be the additional overhead of cleaning it at the end of every callback execution."

What I showed in my answer will NOT be cleared from memory as it is stored in handles. Once data is added to the handles structure and stored using guidata then it is totally unaffected by the callback finishing. Storing the matrix in any other way (e.g. nested variable, appdata, global, etc) will have the same effect: it does not get cleared when the callback finishes. It makes no difference where load is called: once data is in memory it can be stored and accessed without needing to be cleared or loaded again. How often the data is loaded depends on the code's author and user, but this is not restricted by MATLAB's callback workspaces.

If the data is to be used solely with a custom GUI, then I see no reason why it is inappropriate to also load that data within the same GUI. I still don't see any reason for your original advice, nor have you provided any of the requested links to support your original comment.

[Ameer Hamza]

I agree with you that I should have provided a reference to the resources supporting the statement, which I have added now. But still, there is one confusion. Although you added the loaded matrix to the handle in your first callback, what will happen when the first callback is executed again and the following line is executed

S = load('PMelisa01.mat', 'PMelisaD20180404Walkingnone01');

It appears that MATLAB will again load the file, or is there something going on.

It makes sense that for custom GUI, there is no need to load variable in the base workspace. But instead of loading it in a repeating callback function, it might be better to load it in createFcn of the graphics object and assign add it to the handle. That way, repeated calls to load() can be avoided.

[Stephen23]

"It appears that MATLAB will again load the file..."

This is correct: the file will get loaded every time that callback runs. This is simply because of how that GUI has been designed by its author: it may be that that is exactly what the author intended... or maybe not. I have no idea, because the design requirements were not given in the question. Perhaps the data file is changed by an external program, and the GUI should load it again each time. I have no idea, because we were not told anything about this.

As you point out there is no need for the data to be reloaded each time: it would be quite easy to provide a button that lets the user load the data whenever they wanted to, or to add some conditions that check if the data has already been loaded (e.g. check if handles.data exists, or the size, or with a flag), or to load the data once automatically at the start... however these are design considerations for the GUI's author: things to be decided based on what it needs to do and how it should interact with the user and data. It is not my job to decide that.

"it might be better to load it in createFcn of the graphics object and assign add it to the handle"

Personally I am not a big fan of things happening automatically like that (particularly when things go wrong, as they inevitably will...), but that would certainly work.

Answer 1

[Stephen23]

There are several ways to pass data between callbacks:

https://www.mathworks.com/help/matlab/creating_guis/share-data-among-callbacks.html

I personally like using nested functions, as they are very simple and intuitive, but sadly cannot be used with GUIDE. With GUIDE the easiest is to use guidata, for which you will need to:

• callback 1: add the data as a field of the handles structure.
• callback 1: at the very end of the callback save handles using guidata.
• callback 2: the handles structure contains your data as field.

Something like this:

function StartAnimation_Callback(hObject, eventdata, handles)
% hObject    handle to StartAnimation (see GCBO)
S = load('PMelisa01.mat', 'PMelisaD20180404Walkingnone01');
handles.MW = cell2mat(struct2cell(S));
plot(handles.MW(1,1),handles.MW(2,2));
guidata(hObject,handles)
End

and the in the other callback:

function popupmenu1_Callback(hObject, eventdata, handles)
% hObject    handle to popupmenu1 (see GCBO)
ax2 = handles.axes2;
Melissa = handles.MW;
...
end