Skip to content
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

Binding fallback not working on latest 0.9 preview 3 #3139

Closed
braca opened this issue Oct 19, 2019 · 4 comments
Closed

Binding fallback not working on latest 0.9 preview 3 #3139

braca opened this issue Oct 19, 2019 · 4 comments

Comments

@braca
Copy link

braca commented Oct 19, 2019

Hi,

I have a TranslateExtension that I use in Avalonia, and WPF to translate some stuff, the code is pretty simple.

    public class TranslateExtension : MarkupExtension
    {
        public TranslateExtension(string key)
        {
            this.Key = key;
        }

        public string Key { get; set; }

        public string FallBack { get; set; }

        public string Context { get; set; }

        public override object ProvideValue(IServiceProvider serviceProvider)
        {
            ....

            var binding = new BindingExtension($"[{keyToUse}]")
            {
                Mode = BindingMode.OneWay,
                Source = Translator.Instance,
                FallbackValue = fallback,
            };

            return binding.ProvideValue(serviceProvider);
        }
    }

Bascialy, when the is no translation for a specific key (returns null), a fallback value is used instead.
This extension works fine with WPF, and Avalonia 0.8.3.

The problem occurs with the latest version 0.9 preview 3, where it seems that it's ignoring the FallbackValue

Repro project: https://github.com/braca/avalonia-binding-fallback-bug

You can load my repro project, with 0.8.3 it will work perfectly, if you update to the latest 0.9 preview 3, the fallback value won't be used.

Note: When you update to the latest preview, comment this using Portable.Xaml.Markup; in TranslateExtensions.cs

@kekekeks kekekeks added this to To do in @grokys todos via automation Oct 19, 2019
@kekekeks kekekeks added this to To do in 0.9 Release via automation Oct 19, 2019
@kekekeks kekekeks added this to the 0.9 milestone Oct 19, 2019
@grokys
Copy link
Member

grokys commented Oct 21, 2019

@braca I've not had chance to look into this properly, but does it work if you return a Binding rather than a BindingExtension from ProvideValue?

My guess is that Portable.Xaml supported markup extensions returning markup extensions recursively, whereas our XAML compiler doesnt. In fact I'm not even sure that recursive binding extensions should work, it might have just been a "hidden" feature of Portable.Xaml.

@braca
Copy link
Author

braca commented Oct 21, 2019

Hi @grokys,

I've tried to replace

            var binding = new BindingExtension($"[{keyToUse}]")
            {
                Mode = BindingMode.OneWay,
                Source = Translator.Instance,
                FallbackValue = fallback,
            };

            return binding.ProvideValue(serviceProvider);

with

            var binding = new Binding($"[{keyToUse}]", BindingMode.OneWay)
            {
                Source = Translator.Instance,
                FallbackValue = fallback
            };

            return binding;

but the end result was the same

@braca
Copy link
Author

braca commented Oct 26, 2019

@grokys I think this is not a bug after all, my bad. In WPF the behaviour is the same, I thought it wasn't but my WPF code had a small difference, and that makes all the difference.
In WPF I'm using TargetNullValue alongside with FallbackValue.

Removing the TargetNullValue, WPF behaves the same way Avalonia 0.9.
Our translator returns null when there is no translation available for the key. null is a valid 'value' for string, so the correct behaviour seems to be, to use null, instead of the fallbackvalue.

So, I believe that the bug was on 0.8.x where it was behaving differently from WPF :)

Feel free to close it

@grokys
Copy link
Member

grokys commented Oct 30, 2019

Thanks for letting us know @braca. We're intending to add TargetNullValue soon anyway - here's the issue: #2814

@grokys grokys closed this as completed Oct 30, 2019
@grokys todos automation moved this from To do to Done Oct 30, 2019
0.9 Release automation moved this from To do to Done Oct 30, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
@grokys todos
  
Done
0.9 Release
  
Done
Development

No branches or pull requests

3 participants