Alarico; RD already does accept keyboard input in order to support certain devices that do not have a scanner API at all (e.g. MC35).  But the way it is currently designed, it if there IS a scanner API and a scanner CAN be opened, it uses that scanner since it can offer a more robust user experience. The issue comes up that if that scanner is being used by another application AND that other application is asking to scan the SAME kinds of barcodes that RD is trying to scan (PDF417 and linear Code 128), then the attempt to read those barcodes by RD is rejected.  Unfortunately, the way the scanner API works, that indication is not a fatal failure and happens much later in the process than the current code to reject that scanner as not available. We considered trying to put in code to make this work and decided it would be relatively high risk and would have to wait for some time when we did not have devices clammoring for an updated RD client release and there was sufficient demand for this feature. Also, be aware that when using a wedge to scan barcodes into RD, instead of direct access to the scanner API, it is necessary for the wedge to be configured correctly to have the right suffix.  This may or may not be compatible with the way the scanner is being used and hence it may not be possible for RD to interact compatibly with other users of the scanner. Finally, also be aware that scanning using a wedge in RD is highly subject to focus.  If the keyboard focus is not in the right place then when a barcode is scanned, then wedge won't send it to the right place and RD won't receive it.  This can be confusing to users which is why we try NOT to use a wedge to scan into RD unless there is no other choice. If this is a key requirement for a specific customer, please file a GRIP with all the particulars, including the opportunity size and we can evaluate accordingly. Thanks Allan

Wow. I experienced this bug on various devices and firmwares since long time ago, but, actually, I thought it was OK, because two programs (RD and DW) fight for the same resource (Scanner). Funny enough, recently I found one device where RD worked with DW and it made me wonder. The only thing I wished was for RD to be smart enough to see that the scanner is occupied and exit gracefully displaying something like "It seems that the scanner is already in use by another program. Exiting." But this "different code types" thing is really something amazing. I wish I knew more about how programs access scanners in our devices. Will go read EMDK

This issue is just only a part of  many other issue found with the way how RD client manage barcode. In order to made a barcode staging  RD client must take control of the scanner. When a scanner is already active by program (ex datawedge) or by OS (usb scanner seen as HID) rd client is not able to use this readed barcode as suitable barcode x staging. I would like that the RD client accept keyboard streaming info as staging input. So I can use scanwedge/datawedge or USB HID scanner (VC5090 that now accept only staging barcoce done by scanner connected to com1 port) to read staging barcode and send as keyboard input to the RDclient. Cheers Alarico PS: SMSstaging client already this: forward to rd client staging info get from plaintext sms message