Numeric Editfield in App Designer

Hi folks,

How can I write a workspace variable to a numeric editfield? I am trying to use app designer as a GUI and once I run my simulink model, results are going to be in the workspace then I would like to write some of the outputs to the related numeric editfield after running my app. Any idea will be appriciated. Thanks in advance.

Mert

[royed]

Hi! I would want to ask if you are getting the output in a string?

[Adam Danz]

"results are going to be in the workspace"

Which workspace? The base workspace?

Answer 1

[Adam Danz]

To select variables from the base workspace into app designer you need to run the who or the whos function in the base workspace to list the available variables. However, since a callback function is likely evoking this, you'll need to wrap the who/s function in evalin() which is looked down upon for good reason, but I don't see an alternative for this solution (you could, of course, pass the variables directly to the GUI has Stephen commented).

This demo lists all of the variables available in the base workspace and produces a UITable showing the variable name, size, bytes, and class of each variable. The UITable has a checkbox column that allows you to select what variables you want to load into the app.

See the inline comments for detail.

Load some data in your base workspace

Executed from the command window.

% Load some data into the workspace so we have some variables to work
% with. These are a builtin and provided by Matlab.
clear
load patients

Get information about base workspace variables

This will be executed from your App. Perhaps a pushbutton callback will evoke this.

% Before calling the whos function from evalin, we'll do a 
% security check that the whos function is the one provided
% by Matlab.  This reduces the risk of using evalin().
if isempty(regexp(which('whos'), 'built-in *.'))
    error('The built-in whos() function is being overshaddowed.  Do not proceed.')
end
% Get base workspace variable info
baseVarInfo = evalin('base', 'whos'); 
% Convert to table
rowNames = {baseVarInfo.name}; 
baseVarInfo = rmfield(baseVarInfo,{'name','nesting','global','sparse','complex','persistent'});
baseVarCell = [num2cell(false(size(baseVarInfo))),struct2cell(baseVarInfo)']; % selection column
varNames = [{'Select'}; fieldnames(baseVarInfo)];
baseVarTable = cell2table(baseVarCell, 'RowNames', rowNames, 'VariableNames', varNames);

Load the table into your UITable

This can be embedded in your App or it can exist in a separate UIFigure.

fig = uifigure();
uit = uitable(fig, 'position', [20 20 500, 300],...
    'ColumnEditable', [true, false(1,numel(varNames)-1)], 'Tag', 'BaseWorkspaceVarInfo');
uit.Data = baseVarTable; 

Load the selected variables into your app

Check the checkboxes of variables you want to load into the app. Something needs to signal that the selection is complete and that a function should load the variables into the app. It could be a button in the app, or, if the UITable is in a separate figure, closing the figure could evoke this action. The code below will work in any case.

% Find the handle to the UITable (note the tag name assigned to the UITable)
% This step is avoidable if the UITable handle is already stored in app.
uitab = findall(0, 'Tag', 'BaseWorkspaceVarInfo'); 
% Get the user's selection and extract the variable names (varsToLoad).
selection = uitab.Data.Select; 
varsToLoad = uitab.RowName(selection); 
% loop through each variable and store it's values in a cell array. 
varValues = cell(size(varsToLoad)); 
for i = 1:numel(varsToLoad)
    varValues{i} = evalin('base', varsToLoad{i}); 
end

% The variable name is stored in varsToLoad{j}
% The variable value is stored in varValues{j}

[Stephen23]

"...but I don't see an alternative for this solution."

This is begging the question: "given that I want to magically access an unknown number of variables from another workspace, therefore I need to magically access an unknown number of variables from another workspace".

The better solution is to rethink the GUI dataflow: store data in one table/structure/..., pass that as an input argument to the GUI, process the data entirely within the GUI, then pass the data as an output argument. This dataflow has the usual well-known benefits in terms of efficiency, no name collision bugs, etc., but what really makes it worthwhile for me is testability and repeatabilty: almost all of my own functions/classes are written in conjunction with a test script/function, which requires a clear input/output specification and a clean interface to the rest of the world. Messing around with other workspaces makes this difficult to define and/or test reliably.

[Adam Danz]

That's why a table appears showing the variable name, size, bytes, and class of all available variables, allowing the user to select which variable(s) to load. There's still a chance that a variable with the expected name, expected size and expected class doesn't actually represent the expected data which is why it would be better to directly pass the variable(s) to the app. I can imagine the scenario where the user expected the variables to have been updated by the model but instead, values from a previous iteration are passed, unknowingly.

[Athrey Ranjith Krishnanunni]

Hi Adam, I have a question about checking if whos is being shadowed:

In your code,

which('whos')

will be evaluated from the caller's (in this case, the app's) workspace, right?

Would this be able to tell us if it is indeed being shadowed in the base workspace?

e.g. if we have a variable named whos in the base workspace, it will not show up when

which('whos')

is called from the app, right?

I suppose we could try to use

evalin('base','which(''whos'')')

but then that raises the question of checking if which itself is being shadowed. Do you have any thoughts on how that can be done?

[Adam Danz]

You could easily test this by creating a variable 'whos' in the base workspace and running which('whos') from within a function.

In general, avoid naming variable who, whos, which and other common Matlab function names.

But to answer your question, if a variable is named whos in the base workspace and you search which('whos') in a function workspace, the base workspace is not accessible and the matlab base function will be returned unless you have a variable or function named whos within the function workspace.

[Athrey Ranjith Krishnanunni]

Hi Adam, there seems to be a problem with my communication preferences, because I never got to know that you had replied 😅. Apologies for the delay.

I had indeed tested it as you suggested, and got the same result. However, what I wanted was a way to ensure that the user can read their variables from the base workspace into my app even when the functions who, whos, which, exist, etc. are shadowed in their base workspace (like in Curve Fitting Toolbox).

I was able to achieve what I wanted by using

varNames = evalin('base','builtin(''who'')');

Now, if the user tries to shadow/ overload builtin before running my app, MATLAB itself will display a warning, so they know not to expect anything to work properly from that point onwards.

Thanks for your comments! 😊