GUI bug when updating editfield contents (loose focus)?
3 views (last 30 days)
Show older comments
In a calculation application where a user modified the contents of editfields, I would expect that such an editfield looses focus and presents its new value via the 'Value' field to the outside world when one of the following events take place which can all invoke a new calculation based on the contents of editfields:
- you press a menu-item
- you press a button
- you switch to another tab in the tabgroup (you may switch from the Inputs tab to a Results tab and automatically invoke a calculation by that tab switch)
For the tab-switch this does not happen correctly. This means that when building a GUI where a calculation is invoked by switching to a Results tab, the results can be wrong because a modified editfield on another tab may not present its modified contents to the user / calculation function.
I think that in case of a tab-switch, the tabgroup should send a loose-focus signal to all tabs and the elements contained by them.
Question: can this indeed be regarded as a bug? At this time I have no comparison material from other GUI frameworks.
Question: is there are workaround for this behavior without changing the actual setup of the application (the user should be able to switch between tabs and directly see correct results...)?
Test-code:
function Matlab_GUI_edit_refresh_bug
% Clean up.
clc
close all
% Generate a minimal GUI.
%
% Bug issue:
%
% - change the contents of the editor
% - click the button menu item / results tab
% - the editor contents as read back in the button callback is not equal to the atcual editor contents in case
% of the tab switch
%
% Result: calculations can be invoked by a user which uses the wrong input data from the last modified editor.
handles.fig = uifigure;
handles.menu.calc = uimenu(handles.fig, 'Text', 'Calculations');
handles.menu.calc_start = uimenu(handles.menu.calc, 'Text', 'Start', 'MenuSelectedFcn', @callback);
handles.tabgroup = uitabgroup(handles.fig, 'SelectionChangedFcn', @callback);
handles.tab1 = uitab(handles.tabgroup, 'Title', 'Inputs');
handles.tab2 = uitab(handles.tabgroup, 'Title', 'Results');
handles.edit = uieditfield(handles.tab1, 'numeric', 'Position', [10, 70, 100, 20]);
handles.label1 = uilabel(handles.tab1, 'Position', [10, 40, 100, 20]);
handles.label2 = uilabel(handles.tab2, 'Position', [10, 40, 100, 20]);
handles.button = uibutton(handles.tab1, 'Position', [10, 10, 100, 20], 'Text', 'calculate', 'ButtonPushedFcn', @callback);
guidata(handles.fig, handles)
end
function callback(obj, varargin)
handles = guidata(obj);
s = num2str(handles.edit.Value);
handles.label1.Text = s;
handles.label2.Text = s;
end
0 Comments
Answers (1)
Voss
on 28 Aug 2023
Setting handles.edit's ValueChangedFcn to @callback seems to resolve the problem (using R2017b; the problem is not observed in R2022a).
3 Comments
Voss
on 28 Aug 2023
"It seems to indicate that an editfield change callback is triggered only after the tab switch callback has ended"
I think that's right, in R2017b and presumably R2020b. But in R2022a the order is reversed: the editfield callback executes before the tab selection change callback. So maybe upgrading to R2022a (or later, presumably) would be the way to go.
See Also
Categories
Find more on Introduction to Installation and Licensing in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!