Quote: "I used a serial barcode reader for my app because keyboard-input ones are a nightmare seperating barcode and keyboard input. Especially if you want to scan barcodes at ANY time, without having to have a certain edit field active or even visible. "
This is why I have programmed the scanner to send F12 before the code, and F7 afterwards. The F12 key moves the input to the UPC field, and the F7 displays the results.
I went through to try to find a rarely used character, and could not. We apparently use almost every character for one reason or another. Slade got me thinking about windows commands. All of my apps keep track of keyboard input using something like this:
FOR i = 0 to 255
KEY_OLD_STATE(i) = KEY_STATE(i)
KEY_STATE(i) = KEYSTATE(i)
KEY_PRESSED(i) = ( NOT KEY_STATE(i) AND KEY_OLD_STATE(i) )
KEY_PRESSED2(i) = ( KEY_STATE(i) AND (NOT KEY_OLD_STATE(i)) )
NEXT i
Whenever KEY_PRESSED is true, it fires a "KEY_UP" event, and when KEY_PRESSED2 is true, it fires a "KEY_DOWN" event. This small piece of code is what currently could not detect the incredibly tiny key press sent by the scanner. So using IanMs
set message callback "WndProc", I put this together
function WndProc(hwnd as dword, msg as dword, wparam as dword, lparam as dword)
select msg
case WM_KEYUP
if wparam = 0x76 then KEY_STATE(KEY_F7)=1
if wparam = 0x7B then KEY_STATE(KEY_F12)=1
endcase
endselect
endfunction 0
#constant WM_KEYDOWN 0x0100
#constant WM_KEYUP 0x0101
This sets the current state of the key to 1, which then means the next loop my keyboard loop above will think the key was just released, and fire the KEY_UP event as usual.
So far it hasn't missed a scan, so I think we got this one covered. Thanks for everyone's help!
