microsoft / microsoft/microsoft-ui-xaml

x:Bind and DataTemplates updating two way bindings incorrectly for selector based controls

Open
#10,232 3 comments 0 reactions 0 assignees View on GitHub
area-ComboBox area-Lists bug team-Controls team-Core team-Markup
Dominant language
C++
Stars
8.4k
Forks
942
Avg merge
2d 7h
Merged PRs (30d)
105

Description

### Describe the bug

When using x:Bind with DataTemplates collection based controls are resetting selected items to null. This has been happening since I started using the Windows App SDK around version 1.0 and is becoming increasingly hard to code around.

Ones I have noticed are Combobox and ListView (I'm sure there are others). This seems to be related to the Selector Base Class.

https://learn.microsoft.com/en-us/windows/windows-app-sdk/api/winrt/microsoft.ui.xaml.controls.primitives.selector?view=windows-app-sdk-1.6

I have tried to look into the generated code and it seems like the following is happening.

1. A DataTemplates base binding object is set to another object due to the reuse of cached DataTemplates.
2. Selector based sub template controls check if the selected item is in the base binding object's new collection.
3. It's not due to the change of the whole binding object changing.
4. Selected Item is set to null

I have attached a sample project to demonstrate this.
This issue exists in standard WinUI controls and the Windows Community Toolkit ListDetailsView

### Steps to reproduce the bug

1. Open up example project
2. Go to "x:Bind Control INotifyPropertyChanged" page
3. Click on the different list items change
4. You should notice the sub lists "Selected ***: value" TextBlocks are changing to Null
5. Go to "x:Bind Data Template" page
6. Click on the different list items change.
7. You should notice the sub lists "Selected ***: value" TextBlocks are changing to Null

### Expected behavior

When using x:Bind in a DataTemplate the selected items should not be set to null. DataTemplates may contain a multitude of selector based sub controls. Leads to a mess in the ViewModel when trying to determine if the user changed something on the screen.

### Screenshots

![Image](https://github.com/user-attachments/assets/be98de2c-13e6-4f8e-9948-ee6593fe54f4)
![Image](https://github.com/user-attachments/assets/4999bf89-c5f2-49d8-8843-41bf148f596e)
![Image](https://github.com/user-attachments/assets/ab086298-4460-428d-b1c4-eee535457d7e)
[ItemSourceBindingIssues.zip](https://github.com/user-attachments/files/18106900/ItemSourceBindingIssues.zip)

### NuGet package version

None

### Packaging type

_No response_

### Windows version

_No response_

### IDE

Visual Studio 2022

### Additional context

_No response_

Contributor guide

Open the contributing guide

Research direction

Start with the attached ItemSourceBindingIssues.zip sample and reproduce the reset on the “x:Bind Control INotifyPropertyChanged” and “x:Bind Data Template” pages. Read the generated binding code and the Selector base-class behavior described in the report. Done means selector-based controls inside DataTemplates retain their selected items when list items change, with the repro no longer showing null values.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
desktop
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.