A set of tools and technologies that enable developers to build, optimize, and deploy applications and services within the Windows ecosystem.
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