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

Reply via email to