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

SetCommand() messes up with UI controls IsEnabled property #447

Open
TimofeyBurak opened this issue Aug 11, 2021 · 1 comment
Open

SetCommand() messes up with UI controls IsEnabled property #447

TimofeyBurak opened this issue Aug 11, 2021 · 1 comment

Comments

@TimofeyBurak
Copy link
Contributor

TimofeyBurak commented Aug 11, 2021

Description

SetCommand() extension methods manipulate with Enabled/IsEnabled properties of UI elements (whenever possible), which makes it impossible to. properly control Enabled state (with bindings, for. example)

Steps to Reproduce

  1. Set command to a button (button.SetCommand(ViewModel.TestCommand))
  2. Add binding to enabled property (this.Bind(() => ViewModel.IsEnabled, () => button.Enabled) where ViewModel.IsEnabled == false)

Expected Behavior

Button should be disabled

Actual Behavior

Button could still be enabled

Possible Fix

SetCommand should not manipulate Enabled state of the UI elements by default. Maybe it could be an additional feature, possibility to bind to ICommand.CanExecute()

Basic Information

  • Version with issue: 4f060ee
  • Affected Platforms: iOS, Android
@wcoder
Copy link
Member

wcoder commented Sep 8, 2021

Currently, bindings handled this behavior via ICommand.CanExecute() for these controls:

We are restricted by views hierarchy on iOS and should add separate behaviors for views.

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

2 participants