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

Button not enabling when its CanX property returns true #148

Closed
trustieee opened this issue Jul 27, 2020 · 10 comments
Closed

Button not enabling when its CanX property returns true #148

trustieee opened this issue Jul 27, 2020 · 10 comments

Comments

@trustieee
Copy link

trustieee commented Jul 27, 2020

Reproduced in this repo here: https://github.com/mariocatch/stylet-foo

I'm using the default Stylet template with dotnet core 3.1.
I simply added a property/method for reproducing the issue.

<TextBox Text="{Binding Username, 
                Mode=TwoWay, 
                UpdateSourceTrigger=PropertyChanged}" 
         Width="100" Height="100"/>

<Button Command="{s:Action Do}">Foo</Button>
public class ShellViewModel : Screen
{
    public string Username { get; set; }

    public void Do() { }

    public bool CanDo => !string.IsNullOrWhiteSpace(Username);
}

Breakpoint on CanDo property is hit once and never hit again. Changing the value in the TextBox, while calling set, does not retrigger the CanDo property.

I've also tried using backing fields with SetAndNotify, to no avail:

public string Username { get => username; set => SetAndNotify(ref username, value, nameof(Username)); }
@trustieee
Copy link
Author

trustieee commented Jul 27, 2020

I realize I am missing property changed notifications. Through all of the examples I saw I assumed this was handled implicitly by Stylet for me.

After changing my property setters to the following, it works as expected.

public string Username
{
    get => _username;
    set
    {
        SetAndNotify(ref _username, value);
        NotifyOfPropertyChange(() => CanLogin);
    }
}

If there's a more intended way to handle this please let me know - I'll close this in a bit.

@canton7
Copy link
Owner

canton7 commented Jul 28, 2020

Yes, you'll need to raise an INPC event for CanLogin whenever Username changes. I'll make sure the wiki makes this clear.

I normally wire things together in the constructor:

Bind(s => s.Username, (o, e) => NotifyOfPropertyChange(nameof(CanLogin)));

@canton7
Copy link
Owner

canton7 commented Jul 28, 2020

Re-opening as a reminder to improve the docs

@canton7 canton7 reopened this Jul 28, 2020
@haven1433
Copy link

I'd be happy to handle the wiki change if you'd like

@canton7
Copy link
Owner

canton7 commented Sep 3, 2020

Sure, please go ahead!

@haven1433
Copy link

Updated https://github.com/canton7/Stylet/wiki/PropertyChangedBase examples to include the "wire in constructor" version and replaced the update-in-method examples with update-in-property examples to make it more clear. If you're happy with the changes, please close this issue.

@ShemJM
Copy link

ShemJM commented Sep 4, 2020

Hi, I have a question regarding Guard Properties. Wasn't sure where to ask but this thread seems kind of related.

How can I pass the CommandParameter into a guard property? So a button would be enabled/disabled depending on the state of the bound model.

@canton7
Copy link
Owner

canton7 commented Sep 4, 2020

@haven1433 Thank you!

@ShemJM That's a limitation of guard properties, and a reason why guard methods are suggested in #147 (although it's not straightforward). It's probably easiest to bind that thing to another property in the VM, and inspect it from your guard property's getter. Make sure you raise the appropriate INPC events.

@ShemJM
Copy link

ShemJM commented Sep 5, 2020

@canton7 Thanks. I'll give it a go and thanks for Stylet!

@canton7
Copy link
Owner

canton7 commented Feb 15, 2021

The wiki page on guards now uses INPC throughout

@canton7 canton7 closed this as completed Feb 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants