Jason,
It's been regularly reproducable, but absolutely inconsistent, if that helps.
The workaround has been to leave the decoder on (and just disable the
scanning) for the duration of the application. I got this response from a
high-level Symbol developer:
"For issue #1 I would leave the scanner on. The documentation is being
ultra-conservative. When we predict our 10+ hour battery life we assume
the scanner is left powered on at all times. If your unit is going to be
place back in the charger once a day for a full charge then you should have
no problem. Please note, it will take some time for the ScanCmdOpenDecoder
command to execute. 20-30 seconds seems unreasonable, so we will look into
why this is happening."
... FYI.
Regards,
Ben Flaumenhaft
Bear River Associates
>At 01:27 PM 12/13/99 -0800, you wrote:
>>
>>I've seen this on the Symbol devices, too. There's something screwy with
>>the decoder. One thing I've seen on a regular basis is that closing/opening
>>the decoder hangs or delays the Palm in a very unpredictable way. (For
>>example, if you have a form that opens the decoder and other forms close
>>the decoder, returning to that form will sometimes hang the Palm or slow it
>>down considerably).
>>
>>Is this the kind of thing you're seeing?
>>
>
>Yep, thats sounds like it. Looks like it's not anything that I'm doing
>then. Do you know of a case that is reproducable? ("very unpredictable"
>sounds like a no).