Event driven programming in BASIC! Isn't our laptop bitchin'? ON KEY GOSUB line just sets up your event handlers for catching function key presses. So it falls through that to the INPUT #1, which immediately blocks waiting for barcode input.
Seems like what you should expect. You don't need the INKEY$ to catch function key presses, because the model 100 is always scanning for keys and you are using the ON KEY handler to detect function key presses: 10 key on 20 on key gosub 100, 200, 300, 400 30 goto 30 100 ?"FKEY1":return 200 ?"FKEY2":return 300 ?"FKEY3":return 300 ?"FKEY3":return (side note is this code does NOT work in CloudT... so, a bug for me). I'm not sure why you want to hit a key before reading the bar code reader. In your application, hitting the function key should set the *current* shelf #, SH. So, when they hit a key, just save the shelf #. Maybe print it to the screen somewhere so the user knows what the shelf # is currently. I say this because I'm guessing the shelf # doesn't change for each item scanned, so why make the user set it again and again? Save a step. The shelf # is an index into an array of counters in your application DIM SA(4). But whenever a barcode scan is available, it should be read, decoded/checked/saved and if it's good, you can index into the SA array and update your item/shelf counter SA(SH) = SA(SH) +1 What you found in your example is that INPUT#1 focuses the computer's intense, undivided attention on the BCR port and "blocks" waiting for data. I guess no events are triggered while blocked on BCR INPUT. So I'd think you'd want to execute INPUT#1 only if you already know the bar code reader has data, so you don't block. Say you had a RS-232 based reader instead. You could set the ON COM interrupt. Something like this, say if you had a serial port bar code reader. 5 open "COM:98N1E" for input as 1 10 key on 20 com on 30 on key gosub 100,200,300,400 40 on com gosub 500 50 goto 50: ' nothing to do... just wait for interrupts. You could do some background work here instead. 100 SH=1: ?@0,"SHELF ";SH:RETURN 200 SH=2: ?@0,"SHELF ";SH: RETURN 300 SH=3: ?@0,"SHELF ";SH: RETURN 400 SH=4: ?@0,"SHELF ";SH: RETURN 500 INPUT#1,BC$:?BC$:SA(SH)=SA(SH)+1:RETURN Theoretical, and untested :-) This assumes the barcode reader triggers the com port interrupt. The BCR port doesn't work that way. For a Radio Shack bar code reader, I guess you need to find some other way to detect data available. The barcode reader is hooked to a hardware interrupt line, so you're supposed to be able to be event driven. I don't know what the interrupt does. Maybe it's just hooked to the button on the reader? The question then becomes, can you detect this event from BASIC. Probably in line 50 maybe you can IN some register to see if the button is pushed. If it is, then and only then do a INPUT #1 to read the barcode. This avoids blocking and keeps the keyboard functional. The other way is to just go with the flow. Your main processing loop has nothing to do with reading the BCR port. F1, F2, F3, F4 could be for setting the shelf # F5 could be for the user to tell us when to read the barcode port. It's an extra user action (click wand, scan, hit F5 to process data), so sub-optimal, but it should work. -- John. -= Model T's Forever =-
