The minDate is actually one day in the past and the maxDate is actually one day into the future so it shouldn't be a problem with being off by a few milliseconds. There must be something else going on here.
I might debug it and try to see what is going on. Right now, I just check to see if they changed the date beyond the allowed time and pop up a message as a kludge until a true solution to get around the bug is coded. This is second discrepancy I have found this week between how an older version of Android and ICS worked BTW. On Wednesday, September 19, 2012 2:27:23 AM UTC-5, pushbit wrote: > > The updateDate method will call onDateChanged and if the time comparison > logic isn't just right then this could lead to infinite recursion and a > StackOverflowError. I would guess that there's a discrepancy between the > Calendar millis and the Date millis. This could be tricky to get right > unless you're very diligent about setting every time field on both sides > down to the millisecond. In the code below, newDate will have the current > hours, minutes, seconds, and milliseconds, since it hasn't been clear()ed. > The milliseconds from newDate will be greater than the milliseconds from > maxDate if maxDate was created with only day precision (time will be > 00:00:00.000). > > Would it work if you simplified this to get the desired date and then use > that for the super() and init() params? According to the 4.1 sources, it > shouldn't be necessary to call updateDate, but I'm not sure about older > versions. > > pb > ---- > Open Source Android App Developer > Dining Out (with friends) - The History and Future of Your > Food<https://play.google.com/store/apps/details?id=net.sf.diningout> > > > On Tuesday, 18 September 2012 20:53:27 UTC+2, darrinps wrote: >> >> I tried that and it blows it up with a stack overflow every time. >> >> Here is what I did: >> >> public void onDateChanged(DatePicker view, int year, int monthOfYear, int >> dayOfMonth) >> { >> Calendar newDate = Calendar.getInstance(); >> newDate.set(year, monthOfYear, dayOfMonth); >> >> if (newDate.getTimeInMillis() < minDate.getTime()) >> { >> newDate.setTime(minDate); >> view.updateDate(newDate.get(Calendar.YEAR), >> newDate.get(Calendar.MONTH), newDate.get(Calendar.DAY_OF_MONTH)); >> } >> else if (newDate.getTimeInMillis() > >> maxDate.getTime()) >> { >> newDate.setTime(maxDate); >> view.updateDate(newDate.get(Calendar.YEAR), >> newDate.get(Calendar.MONTH), newDate.get(Calendar.DAY_OF_MONTH)); >> } >> else >> { >> super.onDateChanged(view, year, monthOfYear, >> dayOfMonth); >> view.init(year, monthOfYear, dayOfMonth, this); >> } >> >> Once you hit a scroll button it goes to never never land for a few >> seconds then crashes. I tried a couple other permutations too with the same >> result. >> >> >> >> On Tuesday, September 18, 2012 3:31:37 AM UTC-5, pushbit wrote: >>> >>> I noticed that this bug is fixed in JB. But for ICS, I believe you can >>> fix the bug yourself in your DatePickerDialog subclass. Override >>> onDateChanged and after super.onDateChanged() call view.init(year, month, >>> day, this). Unfortunately init will be called twice, but the second time >>> should restore your DatePickerDialog as the OnDateChangedListener. >>> >>> pb >>> ---- >>> Open Source Android App Developer >>> Dining Out (with friends) - The History and Future of Your >>> Food<https://code.google.com/p/dining-out/> >>> >>> >>> On Monday, 17 September 2012 20:25:20 UTC+2, darrinps wrote: >>>> >>>> Looks like onDateChanged never gets called in ICS (and above I assume) >>>> after the very first time the DatePickerDialog is displayed. Here is a bug >>>> that has been filed: >>>> http://code.google.com/p/android/issues/detail?id=25838 >>>> >>>> I tried the work around suggested in it (not calling >>>> super.onDateChanged) but that resulted in a stack overflow, so, does >>>> anyone >>>> have a suggestion to get OnDateChanged working with older versions of >>>> Android (targeting 2.2 and above) running on devices with ICS installed? >>>> >>>> Again, everything works fine with onDateChanged up until version 14. >>>> After that, the call back never takes place. I need to know when the >>>> dialog >>>> has had its date changed. >>>> >>>> Thanks! >>>> >>> -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en