Conversation
|
Hi @simonrozsival so, to be clear, with this PR, code like this: won't need to specify the DataType ( i'm getting warnings for these in net9) or what should I do? |
|
@bcaceiro you would still need to specify the x:DataType somewhere in the parent scope. The compiler needs to know the exact type of the source type so it can turn the at the moment, you need to do this: <Border.Triggers>
<DataTrigger Binding="{Binding Quantity, x:DataType=MyViewModel}"
TargetType="Border"
Value="0">
<Setter Property="IsVisible" Value="False" />
</DataTrigger>
</Border.Triggers>if we remove the restriction, it could look like this: <ContentPage ... x:DataType="MyViewModel">
<!-- ... -->
<Border.Triggers>
<DataTrigger Binding="{Binding Quantity}" <-- this x:DataType would be inherited from the ContentPage
TargetType="Border"
Value="0">
<Setter Property="IsVisible" Value="False" />
</DataTrigger>
</Border.Triggers>
<!-- ... -->
</ContentPage>If you are not worried about non-compiled warnings, for example if your app doesn't have performance issues and you don't have the time to update all the bindings, you can suppress this warning by setting the <NoWarn>$(NoWarn);XC0022</NoWarn>Does this answer your question? If you have some specific problem you want to discuss, I recommend opening a new issue so we can look into it separately. |
|
@simonrozsival thank you for your explanation. Indeed I already have the x:DataType in the parent scope, in this case the Page, that's why I was wondering if I need to replace, like you suggested right now, or in a future release it won't be necessary. I indeed am most interested in compiled bindings and performance. |
|
/azp run |
|
Azure Pipelines successfully started running 3 pipeline(s). |
|
The |
3c3503b to
73fa87a
Compare
|
/backport to release/9.0.1xx |
|
Started backporting to release/9.0.1xx: https://github.com/dotnet/maui/actions/runs/11352802876 |
Description of Change
The
x:DataTypeshould always match the currentBindingContextof the current scope. When you pass a binding to thePickercomponent, the binding context for that binding will be each individual item in the list of items to choose from and not the parent binding context. This is similar to how we have a warning when you don't setx:DataTypeonDataTemplateand instead the data type from the parent scope would be inherited by the template. That is likely an oversight and should be fixed.In the cases mentioned in #25141,
DataTriggerandMultiBinding, the same reasoning doesn't apply, I think. It makes sense for the binding to inherit the parent binding context type.Looking at this design in #22023 again after some time, I don't find it intuitive and rather confusing. Especially since the warning doesn't mention that there is a special rule for "standalone" bindings. Unless we are able to distinguish the "Picker" scenario from the "Multibinding" scenario, I think we should remove the restriction. If we do that, we should also revisit #24513 to match the behavior in runtime XAML parsing.
Issues Fixed
Fixes #25141
Fixes #5342
This restriction was introduced in #22023
This change is also related to #24513