Passing variables in GUI vs. assignin then evalin

Question

Dc215905 2020-3-11

0
链接

此问题的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/510222-passing-variables-in-gui-vs-assignin-then-evalin

评论： Dc215905 2020-3-13

I've looked through multple ways to do this on the forum but I still can't seem to figure it out.

I'm loading a bunch of variables into my GUI that I want to be able to pass to different functions/callbacks (they are the same, right?).

In the past I have done this by:

[fname, path]=uigetfile('*.mat');
File = fullfile(path, fname);
load(File)
assignin('base','com',com);
assignin(many more)

and then in another callback:

com = evalin('base','com')
manymore = evalin('base','manymore')

How do I pass these individual variables between different callbacks so I don't have to always pass it throught the workspace and bring int back (also, what's wrong with doing it this way?)?

I know guidedata(hObject, handles) exist, but I can't for the life of me make it work.

Thanks

2 个评论
显示无隐藏无

Stephen23 2020-3-11

编辑：Stephen23 2020-3-11

"How do I pass these individual variables between different callbacks so I don't have to always pass it throught the workspace and bring int back"

Use nested functions (if you are sensibly writing your own code) or guidata (if unfortunately using GUIDE):

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

This forum also has plenty of working examples. This is a good tutorial to start with:

https://www.mathworks.com/matlabcentral/answers/483657-how-to-create-a-gui

"...also, what's wrong with doing it this way?"

Your current approach is slow, inefficient, obfuscates the code intent, is liable to bugs, and makes debugging harder. Really there is not much to recommend it, but it does seem to be popular with beginners who like everything to magically appear in the base workspace. Your approach will make writing generalizable, efficient, testable code more difficult.

https://www.mathworks.com/matlabcentral/answers/304528-tutorial-why-variables-should-not-be-named-dynamically-eval

Dc215905 2020-3-13

Thank you! There's a lot of valuable info in this post.

请先登录，再进行评论。

请先登录，再回答此问题。

Answer 1

Rik 2020-3-11

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/510222-passing-variables-in-gui-vs-assignin-then-evalin#answer_419581

编辑：Rik 2020-3-11

在 MATLAB Online 中打开

To answer the question of how to do it with guidata:

%this stores data to your figure:
guidata(hObject,handles)
%this retrieves that data:
handles=guidata(hObject)

In your function you can modify or create fields of the struct. If you modify data, don't forget to use the first to update the data stored with the figure.

You can treat the first line as a set() and the second line as a get(). If you have a GUI created with GUIDE the second line is implicitly executed every callback, so you'll only need to use the first line.

1 个评论
显示 -1更早的评论隐藏 -1更早的评论

Dc215905 2020-3-13

Thanks for the simple explanation. Your set() and get() comment made perfect sense.

请先登录，再进行评论。

Answer 2

Peter O 2020-3-11

0
链接

此回答的直接链接

https://ww2.mathworks.cn/matlabcentral/answers/510222-passing-variables-in-gui-vs-assignin-then-evalin#answer_419551

Nested Functions are your favorite friend when working with GUIs. Place the callbacks within the main UI, and they'll be able to access the scope of the parent function.

See: https://www.mathworks.com/help/matlab/matlab_prog/nested-functions.html

And:

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

Whenever possible avoid using evalin and evalc. They permit execution of arbitrary code (including shell commands), so they can be a security risk.

For scoping reasons, it's "dangerous" to place variables into global namespace because they can be accessed and modified by other functions that you might hypothetically have running, and it creates a lot of memory access overhead. And they might overwrite your poor user's code if names overlap. For instance, if you have the variable in the UI called "data," there's a high probability it might overwrite the information the user just loaded in the workspace from data.mat :)