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. With this mode, the issue is very hard to catch (needs a lot of patience)īe aware that Populate Methods Mixed 1st Expanded and Mixed 2nd Expanded suffer from the IsExpanded() crash, see #8275.Perform Repopulate Once many times and inspect the context menu.Select Clear Method RemoveAtEnd() recursive.In the failure case the context menu number is smaller and belongs to an earlier tree node.The number must match the number of the treeviewitem Inspect with right-click on red items the dynamic context menu. Close and reopen the solution (to avoid a weird deployment error). Unfortunately, occasionally it is still observed. With proper node removal, the issue is triggered very seldom. When using Clear() which leaks all nodes the scrambling is very frequent (but not always). The issue strongly correlates with the memory-leaking behavior reported in #8275. 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.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |