Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[API Proposal]: Fallback when binding target type does not match #10746

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.

Sign up for GitHub

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

Jump to bottom
Open
Laniusexcubitor opened this issue Apr 9, 2025 · 4 comments
Open

[API Proposal]: Fallback when binding target type does not match #10746

Laniusexcubitor opened this issue Apr 9, 2025 · 4 comments
Labels
API suggestion Early API idea and discussion, it is NOT ready for implementation

Comments

@Laniusexcubitor
Copy link

Background and motivation

Currently when we use a binding with an interface we get a binding error or warning when the source type does not implement the interface: TargetException:'System.Reflection.TargetException: Object does not match target type.
Sometimes this is completely ok, but we get a nasty binding warning in XAML Binding failures when a FallBack value has been set otherwise a binding error is generated.
I propose a new property on a binding like FallbackOnUnmatchedTargetType that will suppress the resulting binding warning.

API Proposal

public class Binding : BindingBase
{
    // ...
    [DefaultValue(false)]
    public bool FallbackOnUnmatchedTargetType { get; set }
}

API Usage

<TextBox Text="{Binding Path=(namespace:IInterface.SomeProperty), FallbackOnUnmatchedTargetType=True, FallBackValue={x:Null}}" />

Alternative Designs

No response

Risks

This would not change the current behavior except of suppressing the current warning/error. Using the property developers are saying that they know that there will be unmatched objects, and they don't need a warning about it.
@dipeshmsft
Copy link
Member

API is not a requirement for suppressing this behavior, right? One another way could be addition of an app context switch which can suppress the behavior.

@siagupta0202 siagupta0202 added the 📭 waiting-author-feedback To request more information from author. label Apr 11, 2025
@Laniusexcubitor
Copy link
Author

That would suppress the binding errors globally. The proposed API would allow to suppress this on a per binding scope.
It's like suppressing an analyzer locally because the code was reviewed vs just suppressing all. I want to be warned about binding errors. But I'd like to have the option to flag single bindings as being tolerant against datacontexts not implementing the interface the binding path expects.
Currently I often use an IValueConverter that allows to check for a type and set bindings via a trigger on that. But that tactic does not work for all circumstances.

@dotnet-policy-service dotnet-policy-service bot removed the 📭 waiting-author-feedback To request more information from author. label Apr 11, 2025
@miloush
Copy link
Contributor

miloush commented Apr 11, 2025

I agree that API changes shouldn't be used to get rid of warnings. It also seems to be useful to have a warning saying the fallback value is being used. What is the issue with getting a warning?

@Laniusexcubitor
Copy link
Author

The issue with getting a warning is that we have warnings that must be ignored. But this tends to lead to ignoring of all additional warnings and then you can just turn of the warnings completely. If if some developers do care about new warnings, they always have to go through the ignorable warning clutter which is time consuming and frustrating.

@himgoyalmicro himgoyalmicro added the API suggestion Early API idea and discussion, it is NOT ready for implementation label Apr 14, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
API suggestion Early API idea and discussion, it is NOT ready for implementation
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@miloush @Laniusexcubitor @dipeshmsft @himgoyalmicro @siagupta0202