Xamarin.forms: Setting DatePicker MinimumDate unexpectedly changes DatePicker Date property

Created on 10 Mar 2019  路  5Comments  路  Source: xamarin/Xamarin.Forms

Description

Same issue as https://github.com/xamarin/Xamarin.Forms/issues/4413, but now I have a repro. I'd reopen 4413 if I could.

Steps to Reproduce

  1. Set up a DatePicker in XAML, bind Date to D and MinimumDate to MD
  2. Set MD=X and D=Y where Y > X
  3. Observe that D is set to X

Expected Behavior

MinimumDate should only influence Date when less then Date.

Actual Behavior

Date is reset to MinimumDate even when greater than Date.

Basic Information

  • Version with issue: 3.6.0.220655
  • Last known good version: unknown
  • IDE: VS 2017
  • Platform Target Frameworks:

    • Android: 8.1

  • Android Support Library Version: 28.0.0.1
  • Nuget Packages:
  • Affected Devices:

Reproduction Link

https://github.com/mfeingol/repros/tree/master/Xamarin.Forms-5505-MinimumDateIssues

2 bug

Most helpful comment

I looked at this as I thought about picking it up but I have tried everything I can think of and can't recreate. I even tried the reproduction give above.

I think this must have already been fixed in later version of XF or it was a Build issue in the XAML Parser.

Therefore @samhouts I think this can be closed as fixed.

All 5 comments

This is still an issue with 4.0.0.482894.

I have the same issue here, with XF 3.6.0.344457.

Moreover I observed that the behavior is influenced by the order used to set the two properties.
In my ViewModel, if I first set D and then MD, D is correctly binded and everything works.
Instead, if I first set MD and then D, D is incorrect.

I hope that someone can solve this (critical) issue.

Thank you.
-m

I looked at this as I thought about picking it up but I have tried everything I can think of and can't recreate. I even tried the reproduction give above.

I think this must have already been fixed in later version of XF or it was a Build issue in the XAML Parser.

Therefore @samhouts I think this can be closed as fixed.

Can confirm the repro app no longer exhibits the problem, so this looks to have been fixed somewhere along the way to 4.3.0.947036.

I'll attempt to remove workaround in my production app tonight, and will close the issue if successful.

And confirmed.

Was this page helpful?
0 / 5 - 0 ratings