-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
11.2+ : Binding of ItemsSource in a UserControl children is broken if the DataContext isn't explicitly set in the UserControl #17744
Comments
Removing If DataContext is inherited, there's no need to set it via a binding. I'm not sure what sort of behaviour you're expecting here, if the data-context changes what things are bound to, how is binding a datacontext without an explicit source going to work? Changing the data-context would prompt bindings to change, but if the datacontext itself is bound would that prompt itself to change itself? What you are doing sounds very strange to me. Just remove your DataContext binding and everything works fine, because the datacontext is inherited. |
Are you also using a binding on the DataContext itself? I haven't seen any defined behaviour of what it means to bind a data-context like this. I don't even have a conceptualization of what ought to be expected when you attempt to bind that which changes the meaning of what things point to on bindings. So, I would perhaps recommend not doing this and not relying on that kind of behaviour. Can any of y'all find documentation on what the intended behaviour is for Binding a DataContext property? |
If we can get a minimal (as small as one could possibly get) reproduction, then we can get this fixed. |
The binding on itself {Binding .} or {Binding} is commonly use in xaml wpf and even in avalonia repository. |
This works for me
Correctly, and the ItemsSource is populated. Interestingly in your sample. |
Could you please try the build from this PR: #17683? It should solve the issue. |
Here is a smaller sample to reproduce. See the MyUserControl.axaml
I'll try it in the PR: #17683 |
@MrJul , I applied your changes in BindingExpression.cs in the 11.2.2 tag, but the issue remains. |
Okay, I'm reproducing it now. Yes, I can confirm that the grid is necessary to replicate the issue. I'm using an even simpler model and data-context, just showing a list of strings. <UserControl xmlns="https://github.com/avaloniaui"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
x:Class="ControlCatalog.Debugging.Issue1744"
xmlns:local="clr-namespace:ControlCatalog.Debugging;assembly=ControlCatalog"
xmlns:system="clr-namespace:System;assembly=System.Runtime"
x:DataType="local:Issue17744DataContext"
x:CompileBindings="True"
>
<Grid>
<ListBox DataContext="{Binding Path=., Mode=OneWay}" ItemsSource="{Binding Path=Items}" >
<ListBox.DataTemplates>
<DataTemplate DataType="system:String">
<TextBlock Text="{Binding}"/>
</DataTemplate>
</ListBox.DataTemplates>
</ListBox>
</Grid>
</UserControl> But I noticed something interesting. If I swap the InitializeComponent and DataContext assignment it works fine. How curious! If I assign the data-context first and then load the xaml it works. If I load the xaml and then assign the data-context it doesn't work. [Edit] |
I think I've perhaps found the problem... In the above screenshot, the The Which means it's not notified that the data-context has changed Because locally set values override inherited values. So, it doesn't raise the property-changed notification. 🤔 Locally set values override inherited values. Then how is binding to a DataContext supposed to work? |
@Whiletru3 @ can you try my attempted fix in And confirm whether or this this appropriately addresses your issue? |
@ShadowMarker789 : you mention in your PR some test failures. Do I need to test it anyway ? |
Those have been addressed. Those were unit-tests that were helpful in making sure I did not break functionality elsewhere. Please test when you can. |
@ShadowMarker789 : I'll test it next monday, can't do it sooner :-/ |
Hello @ShadowMarker789, I just test the PR (cloning your repo and branch) in my sample AvaloniaListBoxDemo.zip (as is without modification), and the issue is still there. There are no Item in the ListBox Also in my original Sample VirtualizationImagesWithEvents.zip No images (in the listbox) and no red rectangle (in the ItemsColtrol) And tried in my real App (using the CI nuget), the issue still there Did you applied some modification in the samples to get it worked ? |
@Whiletru3 - can you check out latest Avalonia Master Branch and repeat your testing? I had some unit-tests that were failing on an older version of the master branch, but they are now passing in the master branch. When I redownload and relink your project with the Avalonia source latest master I get the following. Is this the issue fixed? Can you confirm fixed on your end? |
@ShadowMarker789 Hello, thanks for all :) Indeed the issue is fixed in 11.2.3 release :) |
Describe the bug
In Avalonia 11.2+, there are some regression regarding the DataContext in UserControl.
When the DataContext of a UserControl is heritated, if a child control is an ItemsControl, the ItemsSource binding remain null.
To Reproduce
Using this example (just put it in the sample folder of avalonia and add it in the solution), as is in 11.1.x you can see 20 images (with random different sizes) with one red recrangle in it like this :
When imported in 11.2 (here in 11.2.2),
The ItemSource of the ListBox is null
In the sample, if you set the DataContext explicitly in the SingleScrollingViewerPanel (the UserControl), it brings back the images
BUT not yet the rectangles.
For the rectangles, in the same file, we need to set the DataContext of the LayoutControl and use an ugly trick (a member of the PageviewModel returning this) or remove the original Binding to point :
This is a blocker issue for us to go in 11.2+ :-(
Here is the package to reproduce :
VirtualizationImagesWithEvents.zip
Expected behavior
As the Datacontext id Inherited, the listbox shouldn't be empty and the LayoutControl for each page as well. The behavior should be the same as in 11.1.3
Avalonia version
11.2.1 11.2.2
OS
Windows, macOS
Additional context
No response
The text was updated successfully, but these errors were encountered: