Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TabView using TabItemsSource binding seems to recycle/cache ViewModel instances? #10297

Closed
elbrandt opened this issue Jan 13, 2025 · 2 comments
Closed
Labels
bug Something isn't working needs-triage Issue needs to be triaged by the area owners

Comments

@elbrandt
Copy link

elbrandt commented Jan 13, 2025

Describe the bug

Is this a bug in TabView implementation? Or what could I be doing wrong?

Summary:

Binding seems to get out of sync when adding and removing tabs from tab TabView.

Minimal Working Example that Demonstrates the Issue:

Code for minimal working example that demonstrates the issue here:

https://github.com/elbrandt/WinUI3_TabView_Binding_Issue

Description:

In a desktop WinUI3 app, using .NET8, I have a TabView that has its TabItemsSource property bound to an ObservableCollection of TabViewModel instances in the page's ViewModel class.

Each time a new tab button is clicked, a ViewModel command method is executed, which instantiates a TabViewModel class and adds it to the ObservableCollection. The TabViewModel class has a single integer property, MyNumber that is initialized to a unique, monotonically increasing integer.

The MyNumber property is bound to both the TabViewItem's Header property, as well as to a TextBlock in a custom control that is the content of the TabViewItem

Behavior (Reproducing):

The Header and and TextBlock should always be in sync, since they are bound to the same member of the object that is the DataContext for the TabViewItem.

However, if you 1. Add two tabs, 2. Close the two tabs, 3. Add another tab, then you will see the two UI elements are no longer in sync.

What is going on? Am I doing something wrong? Or is this a bug in the TabView code?

Thanks in advance!

(I have cross posted this to https://stackoverflow.com/questions/79353040/winui3-tabview-binding-not-updating-correctly-recycling-instances as well, in hopes of getting an answer somewhere, quickly).

Steps to reproduce the bug

clone and build this minimal working example:
https://github.com/elbrandt/WinUI3_TabView_Binding_Issue

when running,

  1. Add two tabs using the button
  2. View the two tabs (activate them by clicking on the headers). Notice the header and contents are in sync.
  3. Close those two tabs
  4. Add another tabNotice that the header and the content are not in sync, even though they are bound to the same VM property.

Expected behavior

The header and the content should be in sync, since they are bound to the same VM property.

Screenshots

Image

NuGet package version

None

Windows version

Windows 11 (23H2): Build 22631

Additional context

If the problem is in my code in the MWE, please help me understand what is wrong that is causing this. Thanks!

@elbrandt elbrandt added the bug Something isn't working label Jan 13, 2025
@microsoft-github-policy-service microsoft-github-policy-service bot added the needs-triage Issue needs to be triaged by the area owners label Jan 13, 2025
@AndrewKeepCoding
Copy link
Contributor

Since TabView uses virtualization for its items, this behavior is expected. You should bind your properties and controls, so they get updated accordingly.

@elbrandt
Copy link
Author

elbrandt commented Jan 14, 2025

I found that if I manually force update of the bindings of the TabViewItem's Content property, then the content will again be in sync. I have updated the MWE code with a branch containing this workaround

https://github.com/elbrandt/WinUI3_TabView_Binding_Issue/tree/workaround

As a general comment:

The 'reuse' of the control and mismatch of bound data context may indeed be 'as designed', and probably helps with performance if there are many many tabs (which is unlikely to be the case...), but I fail to see how this design is 'expected behavior' for anyone using the class. Even if the TabView has no implementation bugs per this design, I'd consider this a 'design bug' (or a 'documentation bug') because it is certainly not the expected behavior as a consumer of the class.

@microsoft-github-policy-service microsoft-github-policy-service bot added needs-triage Issue needs to be triaged by the area owners and removed needs-triage Issue needs to be triaged by the area owners labels Jan 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working needs-triage Issue needs to be triaged by the area owners
Projects
None yet
Development

No branches or pull requests

2 participants