Hi Colin
Colin Mack wrote:
>Thanks Gaurang,
>
>Checksum here is not the problem though -- a bad checksum will result
>in a failure of the download itself -- the appli never gets saved to
>the data folder, so you never get the chance to see the lovely $BIT_at_5%G!<%?(B
>message. Also, it wouldn't work on the other phones, as I know from
>painful experience with getting my crc and download setup working in
>the first place ;)
>
>Any other suggestions?
>
I had the $BIT_at_5%G!<%?(B problem on the sony ericsson for a while, and the
cause was due to a mismatch between the jar size and that specified in
the jad file and the manifest file. I know you're on the panasonic, but
I thought I'd mention it.
I've been following you on the JavaHz list, and I can see you've been
looking at your manifest details. The problems I had arose when I tried
to automate the process of appli creation, and there was an issue of
whether the jar size in the jad file and mf file were the jar size
before or after it had been checksummed.
Now maybe the panasonic follows different rules from the other phones?
Try increasing the jar file size as specified in the mf and jad files to
reflect the checksummed jar file, or the other way round, if thats what
you're doing already.
I would also recommend decompiling an appli that does work on the
panasonic you are testing on and checking the relation between all these
jar size specs, and actual & checksummed sizes of the files.
CHEERS> SAM
Received on Fri Nov 1 05:49:53 2002