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).

Reply via email to