Once we hit the failure mode all future updates will be scrambled. The ones that are changed over the data context with x:bind behave correctly. Once the failure is triggered all these directly modified properties show the wrong value. In the following example (see attached solution TreeStability_FailureCaseOpeningContextMenu.zip) we modify the background color, one of the textbox texts and the context menu by code. Name(text) // <- Will work as textblock entry is updated over the data context with x:bind Winrt::Windows::Foundation::IInspectable const& args) Winrt::Windows::Foundation::IInspectable const& sender, It seems that the datacontext of the flyout is different than the underlying data. Removing and re-attaching the events in code didn't help. As soon as an initial context menu is defined in Xaml it gets swallowed. The event ContextRequested isn't of help either. As we have the UI element inside a template we also cannot use the approach using x:Name (that is documented on every documentation page of MS). But for unknown reasons, the Items Property in MenuFlyoutSubItem is a read-only property from Xaml side. WinUI 3 - Windows App SDK 1.2.4: 17.4 Windows version The number shown in the sub-context menu of 'Dynamic' should match the number of the related tree view item.
They all show the same issue that context menus get scrambled.įor the moment we get the best behavior when defining Opening events in the menuflyout. Instead, we tried with Loaded, Opeing, and DataContextChanged events.
When tree nodes are removed and added the dynamic context menu does not match with the datacontext of the related tree view item.Īs we still have some XML-defined static contextmenu flyouts and our treeview uses template selectors the ContextRequested event will be swallowed. Our application uses contextmenu flyouts that are dynamically configured depending on the tree view item data.