[ODK Developers] ODK Collect crashing (unlikely to do with 1.2 update, but maybe?)

Your attached form seems to be missing.

Also filing an issue on our issue list is helpful as we track progress
on problems there.



··· On Sat, Jul 28, 2012 at 5:23 PM, wrote: > A form I created with build is causing Collect to crash in a (somewhat) predictable way. > > The form itself is quite simple and fairly short (xml attached). It is basically a series of grouped Date Spinners and MultiSelects (labelled x_DK with 1 option, which is what I generally use for Don't Know/No Response). The form passes validation. > > When I swipe through the form without selecting anything, there are no problems. If I swipe around with a couple of the MultiSelects selected, no problem. However, we I get to >11 of the MultiSelects selected, the next swipe causes a crash. The ADB output at time of crash is 'java.util.Date cannot be cast to java.lang.String.' > > I have tried updating and rolling back to different versions of ODK, with no success. And while I am able to consistently replicate the error, it does not seem to be limited to 1 field - that is, if I hit MultiSelects 1-5 and 7-12, it then only crashes when I hit MultiSelect 6. Alternatively, I can do 1-9, then 11-13, then come back and crash it on 10. > > Any help or guidance on this would be very much appreciated. > > > > ADB Output: > W/dalvikvm( 3978): threadid=1: thread exiting with uncaught exception (group=0x40a381f8) > E/AndroidRuntime( 3978): FATAL EXCEPTION: main > E/AndroidRuntime( 3978): java.lang.ClassCastException: java.util.Date cannot be cast to java.lang.String

I believe this is an error with a formula in your form.

The /data/IM32 prompt has this relevance condition:

selected(/data/IM6_group/IM6_ND, '99') and
selected(/data/IM7_group/IM7_ND, '99') and
selected(/data/IM8_group/IM8_ND, '99') and
selected(/data/IM12_group/IM12, '99') and
selected(/data/IM13_group/IM13, '99') and
selected(/data/IM14_group/IM14, '99')

But IM12, IM13, IM14 are date values. I think these should be IM12_ND,
IM13_ND, IM14_ND


··· On Mon, Jul 30, 2012 at 8:12 AM, wrote:

Ugg, sorry. Attached here.

I will certainly file this as an issue on the list as soon as someone
confirms it's not some ridiculous human error issue that I've overlooked.

Thanks again

Mitch Sundt
Software Engineer
University of Washington