Getting variables in function workspace during debugging

I'm creating a mlapp data visualization tool and need to grab all variables in the current function workspace when debugging.

When running the app, while debugging a program, the user should be able to press a button when a breakpoint is reached to pull in all variables in the current function workspace to interact with the var data in the app. One main challenge is when this button is pressed, it goes into a callback function, which has its own function workspace within the app. I am using the below code to get each variable and do what I need to do with it:

variables = evalin('base', 'whos')
for ii = 1:numel(variables)
    data = evalin('base', variables(ii).name);
    % ....
    % do something with data
    % ....
end

I understand that 'base' is not what we want here. However, evalin only accepts 'base' and 'caller' and 'caller' is not correct either since it's a function of the app. So this is unable to grab the variables within the current function workspace when debugging, only the base workspace. Do you have any idea how to grab the variables for the current function you are in programmatically, while debugging?

[David Hill]

Place a stop in the function you are trying to inspect and all of its variables that are assigned at the time will be in the workspace.

[Jeremy]

David Hill -

As described in the original post - 'while debugging a program, the user should be able to press a button when a breakpoint is reached to pull in all variables', I don't think this is the issue.

The issue is that when the button press occurs and the callback is entered, the function breakpoint is no longer the active area of the function call stack.

I don't know of any (easy) way to programmatically navigate back to where the breakpoint is on the call stack.

[Matt F]

Yes Jeremy, that's correct. You will have access to them via the command line but not the app. The question is, how can the button callback function in the app gain access to the current function workspace programmatically.

[Michael Van de Graaff]

I don't know if i understand the question, but I think I might want to for posterity. Let me give a couple ideas of how i'm interpreting what you say:

Interpretation 1: the app (call it app1) is running, and hits a breakpoint within app1, say inside a callback or function within the app. But you also have the base workspace, and you want access to those base variables while debugging, and your question is how to talk to the base workspace while debugging the app.

Interpretation 2: the app is running and you are also doing stuff in the base Matlab workspace and hit a breakpoint in a function NOT within the app, and want to reach into app1 and have access to those variables?

Or are both of those interpretations wrong?

[Matt F]

Interpretation 2 seems to be correct.

The app is running and I am doing stuff within the base Matlab workspace and hit a breakpoint NOT within the app but within the program I was running in the Matlab base workspace. Once I hit that breakpoint, I want to be able to gain access to all the variables in the app wherever that breakpoint is, which is a function workspace from the program I was running in the Matlab base workspace in this case. I then go to the app and press a button with the purpose of retrieving those variables. This brings me into a button callback within the app where I programmatically try to get the variables from the function workspace where the breakpoint is. I don't know of any way to do this programmatically.

[Michael Van de Graaff]

Did you ever solve this problem Matt?

[Matt F]

@Michael Van de Graaff No I have not. My current solution is to call a function using a "favorite command" to update the variables since that will always run in the current workspace even when debugging.

Answer 1

[Steven Lord]

I'm creating a mlapp data visualization tool and need to grab all variables in the current function workspace when debugging.

When you enter debug mode you can switch between function workspaces via icons in the Editor or via the dbup and dbdown functions.

When running the app, while debugging a program, the user should be able to press a button when a breakpoint is reached to pull in all variables in the current function workspace to interact with the var data in the app.

Suppose that the variables in the "current function workspace" have the same name as "data in the app". Are you okay with the "data in the app" being overwritten by some other data (which may or may not be the same size or type or have the same meaning) that happens to have the same name?

Do you have any idea how to grab the variables for the current function you are in programmatically, while debugging?

IMO the answer is "You shouldn't." If you need to check something in the caller's workspace (to check that what your function received is what you expected it to receive) switch workspaces and check the value in situ then switch workspaces back to the workspace where you entered debug mode.

[Matt F]

When you enter debug mode you can switch between function workspaces via icons in the Editor or via the dbup and dbdown functions.

This is true but unfortunately will not work in my case. Once you press the button in the app, dbup and dbdown no longer work since you enter the button callback and are no longer in debug mode.

Suppose that the variables in the "current function workspace" have the same name as "data in the app". Are you okay with the "data in the app" being overwritten by some other data (which may or may not be the same size or type or have the same meaning) that happens to have the same name?

This will never happen because all I am doing is taking the data from the variables in the function workspace and putting it into a WorkspaceTree for the user to view.

IMO the answer is "You shouldn't." If you need to check something in the caller's workspace (to check that what your function received is what you expected it to receive) switch workspaces and check the value in situ then switch workspaces back to the workspace where you entered debug mode.

This is the whole point of the app though. To be able to run the app, while debugging or just generally working in matlab, and inspect your variables and do data analysis on them.