One last scan in the buffer

[smfelsher]

I am using the BarcodeScanner component in a dialog and I'm trying to capture only one (1) scan. I open my dialog and scan a barcode. My bcs-scanned handler will store the barcode results only if the length of the results array is greater than zero (0), and then I want to stop scanning and close the dialog.

scanned(barcodes){
  if(barcodes.length){
    this.barcodes = barcodes
    // Code to stop scanning and close dialog.
  }

  // Some debug code to indicate a `scanned` event occurred.
}

What I'm seeing is that when I click the button to open the dialog again, there is one (1) more scanned result, the scanned method is triggered causing my dialog to immediately close.

For my //Code to stop scanning and close dialog, I have tried just closing the dialog, stopping the scan (scanning prop) then closing the dialog, and hooking into the bcs-stopped event to close the dialog. All of these attempts have not fixed my issue of having one (1) or more "buffered" scans causing my dialog to close immediately.

Any thoughts on how I can handle this situation?

[undecaf]

@smfelsher I suspect that this effect may be caused by an unintended mutation of the scanning attribute. Could you please add :debug="true" to <barcode-scanner> and post the console output?

Thoughts:

• If your scanner component is re-instantiated whenever you open the dialog then the scanning attribute must exist beforehand and must have been set to false, or else video source scanning will start immediately. If the scanning attribute is initialized too late then this may lead to a single scan.
• Scanning two different barcodes alternately could clarify whether the extra result comes from the last scan or from the current one.
• Single scans off a video stream may be unreliable. As an alternative, you could scan continuously until a few consecutive scans or the majority of the most recent scans report identical barcodes.

I updated the online example so that is supports single scans (at label Scanning). In single scan mode, the scanning attribute is simply reset in the bcs-scanned handler.

[smfelsher]

Having had some time to think about it, yes, I need to get more than one (1) consecutive matching scan. I plan to implement that logic, which of course will overcome this issue we're discussing.

Here is the log from the console: ptda-test.edgeovens.com-1660909813308.log

Line 35 will cause this code to run:

  if (barcodes.length) {
    this.barcodes = barcodes
    this.dialog = false
  }

Setting dialog to false closes my dialog and also sets scanning to false.

Line 39 would have been triggered by me clicking a button to open the dialog, i.e. dialog = true, which also causes scanning to be true. Line 45/46 is that one (1) buffered scan.

[undecaf]

@smfelsher Log lines 39-41 indicate that the video stream is not yet playing by the time scanning is set to true. This may be due to the fact that starting a video is an asynchronous process which takes some time to complete.

This effect is not harmful since the scanner component (re-)starts scanning whenever a video (re-)starts playing (lines 42-44). This is followed by exactly one bcs-scanned event that passes one barcode (lines 45-46). Afterwards, scanning stops (lines 47-49) because scanning was reset. Everything appears to be working as it should.

However, is the barcode that you receive in line 46 is not the correct one but the one from line 35? This may be caused by video frames buffered earlier but unbuffered only when the video was restarted. If such a frame is scanned then the first scan will see and report the previous barcode. Having the video stream playing continuously (if possible) will fix this and will also avoid false scanner starts as in lines 39-41.

[smfelsher]

The barcode that I'm receiving from line 46 is the same barcode that was scanned in line 35.

I am in the process of implementing the multiple matches logic mentioned earlier. I'll report my results for the record.

Thank you for your time.

[smfelsher]

So, as expected, the filtering (waiting for 5 matching requests) works for me. The extra scans that occur after I get a match and start to close the dialog/scanner are filtered away the next time a scan is invoked.