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
