The reason why this happens is because of the order of events in this workflow, and how the breakpoint disrupts them. The typical event order goes like this:
<user mousedown>
-> ButtonDownFcn (Tab/any other component with a ButtonDownFcn)
<user mouseup>
-> SelectionChangedFcn (TabGroup)
-> WindowButtonUpFcn (Figure)
When a breakpoint is set in the 'ButtonDownFcn', it stalls the processing of the 'ButtonDownFcn', which allows the interactive tab selection to Tab 2 to go through. Then, when you let the code continue from the breakpoint, the 'ButtonDownFcn' finishes processing, which then programmatically sets the Tab to Tab 1.
Uninterrupted, the ButtonDownFcn is processed first (to set the SelectedTab to Tab 1), and then the selection is changed to Tab 2 because the selection event happens after the mousedown (i.e. during the mouse up). So the app ends up on Tab 2.
As a workaround for this, instead of setting the 'SelectedTab' in the 'ButtonDownFcn', the you can use the "TabGroup's" "SelectionChangedFcn" to change the "SelectedTab". That will ensure that it is processing the event after the Tab is selected.
The callback would look something like this:
% Selection change function: TabGroup
function TabGroupSelectionChanged(app, event)
selectedTab = app.TabGroup.SelectedTab;
if (selectedTab == app.Tab2)
app.TabGroup.SelectedTab=app.Tab;
end
end
