-
Notifications
You must be signed in to change notification settings - Fork 1.8k
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
ListView sets Cell's BindingContext to self, causing multiple warnings and/or InvalidCastExceptions #13754
Comments
This makes ListView completely broken on WinUI, as you are not able to present views based on the binding |
Verified this issue with Visual Studio Enterprise 17.7.0 Preview 3.0(net8). Not repro on windows platform with sample project. |
Hi @DanTravison. We have added the "s/try-latest-version" label to this issue, which indicates that we'd like you to try and reproduce this issue on the latest available public version. This can happen because we think that this issue was fixed in a version that has just been released, or the information provided by you indicates that you might be working with an older version. You can install the latest version by installing the latest Visual Studio (Preview) with the .NET MAUI workload installed. If the issue still persists, please let us know with any additional details and ideally a reproduction project provided through a GitHub repository. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time. |
Still occurs in .NET 8 Preview 6 |
@homeyf I'm curious if you've reviewed the debug output for the sample because I see no change in the behavior. I installed .Net Maui Preview via Visual Studio installer, changed the project to build for .net 8 and MauiVersion8.0.0-preview.6.8686 and and debug output is flooded with InvalidCastException messages. A more deterministic repo is to check System.InvalidCastException in the VS Exceptions Settings window. You'll see an InvalidCastException with 'Object must implement IConvertible.' for each bound object. If you step up to the caller in the call stack, you'll see BindingExpression.TryConvert attempting to convert ListVIewBinding.ViewModels.ColorsViewModel to IEnumerable when it binds StackView's BindableLayout.ItemsSource property; which expects an IEnumerable. The actual binding expression is ItemsSource="{Binding Nested.Colors}" which should resolve to ColorsViewModel.Nested.Colors. Eventually, it does but not before first failing to bind the invalid value. As an aside: If ColorsViewModel implemented IEnumerable, the binding would cause StackLayout to binding to an invalid IEnumerable on the first pass. Note that the sample has two repros, both defined in mainpage.xaml. To repro the second, comment out the first Label and ListVIew elements and uncomment the second Label and ListView elements. When you build and run the sample, you will now see two paris of warnings for each bound object. This is also caused by the same problem of binding the parent's BindingContext to each bound object. The target, defined by ListViewItemTemplate, expects a NamedColor with a Name and Color property but receives a ColorsViewModel. |
I've updated the sample to add a .Net 8 and Maui 8.0.0-preview.6.8686 solution and csproj. |
still a critical issue with version 8.0.0-preview.7.8842 which completely breaks Executing this command fails of course because the Type of the StackTrace:
And of course the output log is filled with Binding Diagnostic Errors:
My Repro: Related Issues: EDIT: anyone found a workaround yet? this used to be fine with .NET 7! |
The ListVIew and CollectionView issues look similar, but they are very different, as far as I can tell. They do not share the same code that was changed in 8.0.0-preview1. The CollectionView issue is a regression in 8.0.0, but this ListView issue presents identically in both 7.0.0 and 8.0.0. Both are important, although the CollectionView issue takes priority as it is actually preventing the bindings from resolving and thus the application is broken entirely. From my testing, the ListView bindings do resolve, despite the many irritating warnings. |
Duplicate of #8433 |
If you're using a DataType on your DataTemplate and you find that the items are not showing up at all, you may be hitting this issue instead: #11956 |
Description
When ListView has an ItemsSource and ItemTemplate defined, the ViewCell.BindingContext for the ItemTemplate is initially set the BindingContext of the ListView itself instead of the associated ItemsSource value.
The problem occurs in Maui when the Element.SetParent is called on the Cell. This calls BindableObject.SetInheritedBindingContext which ends up setting the ListView's BindingContext on the ViewCell instead of the intended value from the ItemsSource. This propogates down the contained View's ItemsSource which, in the StackLayout case, expects an IEnumerable. Since the ListView's BindingContext is not an IEnumerable, an InvalidCastException(Object must implement IConvertible) is raised by Convert.ChangeType. If the ListView's BindingContext does implement IEnumerable, a flood of BindingDiagnostics: Warnings occur for each Cell also due to the incorrect value.
I see this sequence occur twice for each cell as the ListView is populated causing a user noticeable delay in displaying the associated page.
With the simpler case of an ItemTemplate that does not bind to an IEnumerable, numerous warnings are output as each View binding is resolved. For a large list, this is prohibitive.
The view eventually populates after multiple binding failures. In the InvalidCastException case, at least 2 failures per ItemsSource value occur before success. I have not determined the number of failures for the 'simpler' case.
I can repro this on Windows but do not see it on iOS, macOS, or Android.
Steps to Reproduce
See the referenced sample project.
Link to public reproduction project repository
https://github.com/DanTravison/ListViewBinding
Version with bug
7.0 (current)
Last version that worked well
Unknown/Other
Affected platforms
Windows
Affected platform versions
10.0.19041.0
Did you find any workaround?
No.
The only way I've found to avoid the issue is to not use ListView. However, I have not found a viable alternative that provides item-level scrolling.
Relevant log output
No response
The text was updated successfully, but these errors were encountered: