Strange processing in npp when a barcode scanner is used for input

John Liudr

Here is what happened:
I have a barcode scanner and am scanning an ID card. In notepad, every scan ends with a new line so the next scan appears on the next line. I’ve scanned lots of times and every time it works as expected, starting a new line after the barcode.
But if I use npp, start a new file, no language setting nothing, just a new file, I scan, then after first dozen scans that produced weird results of some scans having no new lines, it settles into every 5 scans there is a new line, not every single scan. I can see the line ending being CR LF.

So what processing is happening in npp to have caused this issue? I don’t have the scanner with me to make a screen shot. I’ll post a screen shot with all symbols showing or maybe even a video of notepad vs npp.

FYI, a barcode scanner emulates a keyboard so the scans are literally sent to the computer as key presses. The key presses are sent rather quickly though, faster than a human can type, and then at the end of the stream of key presses, an ENTER key is sent and a key release.

PeterJones

@John-Liudr ,

In theory, Notepad++ should just accept the typing as is.

Maybe you have a plugin or some other external application that is interfering with receiving the fast “typing” of the scanner.

However, if it were just about the speed, I would think it would be rather random in the barcode scan where the missing characters would be – I would think it would be just as likely to be that Notepad++ missed some other character in the scan than the final CRLF. So your symptoms don’t make much sense to me.

In addition to a comparison from windows notepad vs Notepad++, supplying your Notepad++ ?-menu’s Debug Info might be informative.

John Liudr

Thanks. I suspect some internal process in npp. I wonder what type of process would reinterpret keyboard inputs in such a regular manner. I asked someone else with the same scanner to replicate my issue on their system and the issue was replicated.

I’ll post debug info once I get home and run some tests.
The barcode was exactly 16 bytes long plus an enter key. So 5 such barcodes is 80 bytes when the enter key gets read, every 5 barcode scans, or 80 characters. Almost sounds like a terminal with 80 characters.

Terry R

@John-Liudr said in Strange processing in npp when a barcode scanner is used for input:

I’ll post debug info once I get home and run some tests

One of the tests you can perform is to run Notepad++ (NPP) without any plugins. Depending on what version of NPP you have the command line argument can be different to what I show. Use the ? menu option, then “Command Line Arguments” to get your argument, but mine (on ver 8.1.5) is:

Try that to see if it helps. Let us know that result along with debug info.

Terry

PeterJones

@John-Liudr ,

I think I figured it out.

I wrote up a perl program that uses Win32 API calls ↗ to send keys equivalent to typing, and was able to vary the speed; by slowing it way down, I was able to see what was going on.

I had assumed your barcodes were UPC/EAN13 or ISBN13 or similar, so numeric-based. And then I made a list of about 5 ISBN13.

When I had it type that fast, I saw something like

… and running it again on the same file, it now resulted in

… with exactly the same sequence.

Slowing it down to 100ms per key, I was able to easily see the auto-completion box pop up. And it hit me: ENTER is the way to accept the autocompletion input.

Since I was with 13-digit numbers, I turned Settings > Preferences > Auto-completion and checked on ☑ Ignore Numbers. With ignore numbers turned on, it did the 5 lines that would be expected

(same output even when I put it at the fastest typing speed the library would allow, which I think is 25ms, even if I program less than that)

I was typing this second post as you made your reply, so I changed the test data set to 16 bytes of alphanumeric, and put those into my example data and ran that. Since it’s not all numbers, auto-complete came back, so the ENTER was being interpreted as “accept the auto-complete” again, rather than “type a newline sequence”. But if I turned off ☐ Enable auto-completion on each input, then it properly did separate lines for each 16 character strings.

I am 95% confident that the problem is not a plugin, and not the barcode typing being too fast and missing characters, but rather that auto-completion is intercepting your ENTER, so it’s not making it to the editor. I believe you will have to turn off auto-completion when you are inputting data with your barcode scanner.

—

#!perl

use 5.012; # strict, //
use warnings;

use Win32::GuiTest qw(:FUNC);
my @ean13 = qw(
    9780856488380
    9780060012811
    9780380977028
    9780061092967
    9780764504600
);
my @sixteen = qw(
    0123456789abcdef
    fedcba9876543210
    thisisastring016
    andanotherstring
);
for (@sixteen) {
    $_ .= "{ENTER}";
    SendKeys($_, 1);
}

(I might not have even noticed the issue, except I was running the script in the editor that I was editing the script, so the file already had those words above the place where I was typing, thus being found for auto-complete)

John Liudr

Oh my goodness! You software people really amazed me today! I’m more of a hardware person despite my programming experience. I would have whipped up an emulator dev board to keep sending HID key strokes until I figure it out. I could have had a potentiometer on the dev board to vary speed though. That was what I was thinking, not at all in the way you did at all. So it was auto complete LOL!!! You made my day @PeterJones

PeterJones

@John-Liudr said in Strange processing in npp when a barcode scanner is used for input:

I’m more of a hardware person despite my programming experience. I would have whipped up an emulator dev board to keep sending HID key strokes until I figure it out.

Understandable. I don’t have access to a barcode scanner or a dev board that can emulate keyboard input, so I had to come up with some software way of mocking it. Fortunately, in testing my “PerlScript” library for automating Notepad++, I did learn how to make perl “type” at Notepad++, so it quickly came to mind.

John Liudr

Thanks again @PeterJones Use whatever you have at hand to solve random questions you encounter is a great demonstration of problem solving skills! Maybe I should google how to do that in Python. I’m happy with Python. I’ve not used Perl for a very long time.