InvokedItemContainer is not NavigationViewItem occasionally for NavigationView of a WinUI app

Hong 1,746 Reputation points
2026-11-13T03:53:43.89+00:00

A WinUI app has a typical NavigationView, with nothing special:

        <NavigationView
            x:Name="NavView"
            Grid.Row="1"
            OpenPaneLength="150"
            IsPaneOpen="False"
            PaneDisplayMode="Left"
            IsPaneVisible="{Binding bFullScreen, Converter={StaticResource InverseBooleanConverter}}"
            IsSettingsVisible="True"
            Loaded="NavView_Loaded"
            ItemInvoked="NavView_ItemInvoked"
            IsBackButtonVisible="Auto"
            IsBackEnabled="True"
            BackRequested="NavView_BackRequested">

            <NavigationView.MenuItems>
                <NavigationViewItem 
                  Icon="Home" 
                  Tag="mainpage"/>
                <NavigationViewItem 
                  Icon="Up" 
                  Tag="upgrade" 
                <NavigationViewItem 
                  Icon="Help" 
                  Tag="help" 
                  SelectsOnInvoked="False"/>
 ...
            </NavigationView.MenuItems>

            <Frame x:Name="ContentFrame"/>
        </NavigationView>


private async void NavView_ItemInvoked(NavigationView sender, NavigationViewItemInvokedEventArgs args)
{
    try
    {
        if (args.InvokedItemContainer is not NavigationViewItem item)
        {
             ...
        }
        else if (args.IsSettingsInvoked)
        {
            ContentFrame.Navigate(typeof(Settings));
        }
        else
        {
            switch (item.Tag)
            {
                case "mainpage":
                    ContentFrame.Navigate(typeof(MainPage));
                    break;
 ...
  
                default:
                    Utility.LogMessageJsonAsync("NavView_ItemInvoked: Unhandled item.Tag: " + item.Tag);
                    break;
            }
        }
    }
    catch (Exception ex)
    {
...
    }
 
}

The app's analytics occasionally reports:

args.InvokedItemContainer is not NavigationViewItem

I can never reproduce this on a dev machine. When this happens:
args.IsSettingsInvoked: False

args.InvokedItemContainer?.GetType().FullName: null

args.InvokedItem: null

NavView.SelectedItem?.ToString(): null

Could anyone shed some light on the possible causes of this?

Windows development
Windows development

A set of tools and technologies that enable developers to build, optimize, and deploy applications and services within the Windows ecosystem.

0 comments No comments

1 answer

Sort by: Newest
  1. AI answer

    2026-11-13T03:54:35.76+00:00

    A normal menu-item invocation should provide an InvokedItemContainer, so handle Settings first, ignore the all-null event defensively, and treat recurring instances as a likely WinUI control defect rather than assuming every invocation is a NavigationViewItem.

    InvokedItemContainer is declared as NavigationViewItemBase, not specifically NavigationViewItem; InvokedItem is the corresponding data item. ^1^ ^2^

    Use this handler structure:

    private void NavView_ItemInvoked(
        NavigationView sender,
        NavigationViewItemInvokedEventArgs args)
    {
        if (args.IsSettingsInvoked)
        {
            ContentFrame.Navigate(typeof(Settings));
            return;
        }
    
        if (args.InvokedItemContainer is not NavigationViewItem item)
        {
            // Ignore an invocation that has no usable item/container.
            LogUnexpectedInvocation(sender, args);
            return;
        }
    
        switch (item.Tag as string)
        {
            case "mainpage":
                ContentFrame.Navigate(typeof(MainPage));
                break;
            case "upgrade":
                ContentFrame.Navigate(typeof(Upgrade));
                break;
            case "help":
                ContentFrame.Navigate(typeof(Help));
                break;
        }
    }
    

    Checking IsSettingsInvoked first is important because Settings is a distinct invocation case and should not depend on casting its container.

    What the captured values mean

    ItemInvoked represents an interaction such as a click or tap on a menu item. ^3^ It can also be caused by equivalent mouse, keyboard, or other input, and it is raised even when the item is already selected. Consequently, SelectedItem == null does not by itself explain or invalidate the event. ^4^

    However, this complete combination:

    • IsSettingsInvoked == false
    • InvokedItemContainer == null
    • InvokedItem == null
    • SelectedItem == null

    does not correspond to a documented normal invocation of one of the static NavigationViewItem elements shown. The available information therefore does not establish an application-side cause. In particular, it does not support attributing the event to binding, the Frame, or SelectsOnInvoked="False".

    There are existing NavigationView control defects involving selection state, including failure to clear the visual selection after SelectedItem becomes null, which confirms that the control’s internal selection and displayed state can diverge. It is not an exact match for this null-event report, so it should not be treated as the identified cause. ^5^

    Capture enough information for a reproducible WinUI report

    Log the following without dereferencing the container:

    private void LogUnexpectedInvocation(
        NavigationView sender,
        NavigationViewItemInvokedEventArgs args)
    {
        Utility.LogMessageJsonAsync(
            $"Unexpected NavigationView invocation; " +
            $"settings={args.IsSettingsInvoked}; " +
            $"itemType={args.InvokedItem?.GetType().FullName ?? "<null>"}; " +
            $"containerType={args.InvokedItemContainer?.GetType().FullName ?? "<null>"}; " +
            $"selectedType={sender.SelectedItem?.GetType().FullName ?? "<null>"}; " +
            $"paneOpen={sender.IsPaneOpen}; mode={sender.PaneDisplayMode}");
    }
    

    Also record externally:

    • Windows App SDK package version.
    • Windows version/build.
    • Packaged versus unpackaged deployment.
    • Input method immediately preceding the event: mouse, touch, keyboard, accessibility/UI Automation, or programmatic action.
    • Whether MenuItems, SelectedItem, IsPaneOpen, PaneDisplayMode, or the containing page was changed around the same time.
    • Whether navigation or menu mutation occurs in another SelectionChanged, Loaded, or focus handler.

    If the same Windows App SDK/version and interaction pattern recur, create a minimal project and file a microsoft-ui-xaml issue containing the log and reproduction sequence. Do not navigate from the all-null event; returning safely prevents accidental navigation while preserving diagnostics.


    References

    1. NavigationViewItemInvokedEventArgs.InvokedItemContainer Property-Definition
    2. NavigationViewItemInvokedEventArgs.InvokedItem Property-Definition
    3. NavigationView.ItemInvoked Event-Definition
    4. NavigationView
    5. #8266 NavigationView Selection not cleared while setting SelectedItem property as null
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.