Am trying to get this done with the hardware I have; e.g. WAND and MT. Ultimately iPhone/Android would be the preferred solution, but I do not have the experience to write a library to redefine a smart phone camera as a BCR. An array is impractical at this point in the project as the number of shelves (SH) and product faces (FA) is unknown until the physical (plan-o-gram) paper is in hand. The end would be two programs: one to build a list database of string data with one record/string per product. The string to be composed of:
SH$+PO$+FA$+UPC$ where SH$=CHR$(32+SH), PO$=CHR$(32+PO), and FA$=CHR$(32+FA) adding only three bytes to each UPC$ and appending that string to the file. I do adjust position (PO) and face (FA) by keeping track of the last UPC$ read. If the same UPC is read then add one to FA. If a new UPC is read then add one to PO. I was hoping this would keep user intervention down to only adjusting for the shelf using the ON KEY routine, included +/- for all three (SH,PO, and FA) using F1-F6 to allow the user a way to make corrections before scanning a UPC. The string is then built and appended to the file. The second part, or program two, is to read the created file once to DIM and then again to fill an array. A merchandiser would then scan a removed product UPC to identify if/where the product is to be located. SH$, PO$, and FA$ are separated from UPC$ (the record) with INSTR$ and the ASC of SH$, PO$, and FA$ minus 32 is assigned to SH, PO, and FA respectively and then displayed with UPC$. At least this is what I had hoped I could accomplish. Unfortunately, it looks like I will have to take a different approach in scanning for input while also listening for the BCD. Thanks, GregS <>< On 10/26/19 1:40 PM, John R. Hogerhuis wrote: > 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 :-) >
