CODEWITHSUNDEEP
uwpuwp-xaml
Brian Wilson
Brian Wilson

Reputation: 31

App running in Anniversary Update doesn't show CommandBar PrimaryCommands buttons until you select the More (...) menu

I have written an app that works works correctly in Windows 10 builds 10586 and 10240, but not in build 14393 (Anniversary Update).

When running in the Anniversary Update build, the problem is that buttons in my command bar's PrimaryCommands area do not appear. If you show the SecondaryCommands area (by selecting the "..." menu on the right end of the command bar), then the buttons in PrimaryCommands magically appear, in addition to the secondary commands. Then the primary command buttons remain visible throughout the remainder of the session as they should.

But this problem only occurs in build 14393. In earlier Windows builds, the CommandBar buttons appear immediately, as they should. You don't have to show the secondary commands to make the primary commands appear.

Note that I am using VisualStateManager (with the GoToState method) to set different visibility states for my buttons. Buttons appear or disappear depending on the current context.

The CommandBar component is located in the main app page. In the same page, I also have a Frame in which I load various Pages as the user chooses various navigation options.

I call the GoToState method when the user navigates to a different page (from the Frame's Navigated event), to set the CommandButton visibility states based on the selected page:

// Change the visual state of command buttons based on the page selection
string pageType = ContentFrame.CurrentSourcePageType.Name;
var stateFound = VisualStateManager.GoToState(this, pageType, false);

Here are my visual states, defined in the page's XAML markup:

<VisualStateManager.VisualStateGroups>
    <VisualStateGroup x:Name="SelectedPageStates">

        <VisualState x:Name="ProductsPage">
            <VisualState.Setters>
                <Setter Target="CommandDirections.Visibility" Value="Collapsed" />
                <Setter Target="CommandShare.Visibility" Value="Collapsed" />
                <Setter Target="CommandPrint.Visibility" Value="Collapsed" />
                <Setter Target="CommandSettings.Visibility" Value="Visible" />
            </VisualState.Setters>
        </VisualState>

        <VisualState x:Name="NewsPage">
            <VisualState.Setters>
                <Setter Target="CommandDirections.Visibility" Value="Collapsed" />
                <Setter Target="CommandShare.Visibility" Value="Collapsed" />
                <Setter Target="CommandPrint.Visibility" Value="Collapsed" />
                <Setter Target="CommandSettings.Visibility" Value="Visible" />
            </VisualState.Setters>
        </VisualState>

        <VisualState x:Name="MapsPage">
            <VisualState.Setters>
                <Setter Target="CommandDirections.Visibility" Value="Visible" />
                <Setter Target="CommandShare.Visibility" Value="Collapsed" />
                <Setter Target="CommandPrint.Visibility" Value="Collapsed" />
                <Setter Target="CommandSettings.Visibility" Value="Visible" />
            </VisualState.Setters>
        </VisualState>

        <VisualState x:Name="SalesPage">
            <VisualState.Setters>
                <Setter Target="CommandDirections.Visibility" Value="Collapsed" />
                <Setter Target="CommandShare.Visibility" Value="Collapsed" />
                <Setter Target="CommandPrint.Visibility" Value="Collapsed" />
                <Setter Target="CommandSettings.Visibility" Value="Visible" />
            </VisualState.Setters>
        </VisualState>

    </VisualStateGroup>
</VisualStateManager.VisualStateGroups>

As I said, the code works fine in Windows builds prior to 14393. But in build 14393, the PrimaryCommands are not visible until the user shows the More (...) menu. I'm wondering what may be different in build 14393 to cause this to happen.

Upvotes: 1

Views: 266

Answers (1)

Filip Skakun
Filip Skakun

Reputation: 31724

I've had problems with that myself. I think there's a problem in the new IsDynamicOverflowEnabled property where it sometimes causes buttons to inadvertently overflow into the secondary commands dropdown. For C++ the fix was to disable that new feature like that:

if (Windows::Foundation::Metadata::ApiInformation::IsPropertyPresent(L"Windows.UI.Xaml.Controls.CommandBar", L"IsDynamicOverflowEnabled"))
{
    this->CommandBar->IsDynamicOverflowEnabled = false;
}

The CommandBar control seems to have a bug where user code collapsing buttons completely breaks the dynamic overflow logic.

Upvotes: 1

Related Questions