TabControl ShowButtonOverflow Behavior

Describe the bug There are two things which I found strange.

1. First the button overflow is shown before the space is filled.

This is due the TabControl.UpdateOverflowButton which uses a >= instead of > (changing it fix the behavior):

private void UpdateOverflowButton()
{
    if (!IsTabFillEnabled)
    {
        _itemShowCount = (int)(ActualWidth / TabItemWidth);
        _buttonOverflow?.Show(ShowOverflowButton && Items.Count > 0 && Items.Count >= _itemShowCount);
    }
}

1. Second, if you select an invisible tab using the menu which requires the scrollviewer to scroll, the tab is moved instead of simply being selected.

This is due the _buttonOverflow.Click event (TabControl.cs line 348):

if (index >= _itemShowCount)
{
    list.Remove(actualItem);
    list.Insert(0, actualItem);
    // REST OF CODE

I found this a strange behavior. I expect the tab to be selected, not to be moved. I’ve changed as following:

if (index >= _itemShowCount)
{
    _scrollViewerOverflow?.ScrollToHorizontalOffsetInternal((item.CurrentIndex - this.SelectedIndex) * TabItemWidth, 0);
    // REST OF CODE

The above in order to work requires an addition in TabControl.xaml (line 174) to enable the right style.

EDIT: I removed IsScrollable = True condition and included IsTabFillEnabled = false. I guess scrolling should be implicit if you don’t use IsTabFilled.

<MultiTrigger>
    <MultiTrigger.Conditions>
        <Condition Property="IsTabFillEnabled" Value="False" />
        <Condition Property="ShowOverflowButton" Value="True" />
    </MultiTrigger.Conditions>
    <Setter Property="Template" Value="{StaticResource TabControlPlusScrollableTemplate}" />
</MultiTrigger>

Contributions I don’t want to bother too much the author, I can prepare a PR if required. On the other end, I’m not that expert and I don’t want to push modifications prior some confirmation.

Thanks for the great controls and thanks in advance for any support. Regards

[codingdna2]

Done! Let me know what you think. Kind Regards, D.

[codingdna2]

I’ve been checking the VS behavior and is like I’ve described here (and it’s also more complex). By the way, I would like to contribute and I’ll do my best to provide you with a PR on this. I’ll use this issue to keep track of modifications.

• Button overflow is shown when Tabs space is full
• Selection of a tab outside the visible area move the scrollbar
• New tab when the tab area is full, should move the scrollbar
• During resize, the active tab should be kept visible

About VS behavior on (2): Visual Studio switch the order inside the context menu but not the order of the tabs. In fact the context menu is bound to the navigation order while the UI only keep the position. As HandyControl doesn’t handle the navigation order, I guess the correct behavior is the suggested one. This feature (navigation order) can be a future enhancement.