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



  • 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.



  • @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.



  • 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.



  • @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:

    68698652-fd21-4c44-ab3f-73d437ca99bb-image.png

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

    Terry



  • @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
    3f8fbea0-04ce-4a20-9892-5b0caa1ae703-image.png
    … and running it again on the same file, it now resulted in
    be09a8c6-7d05-4499-86a3-92caadb9ec25-image.png
    … 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
    76090909-560b-49a8-807e-2b5862d401f2-image.png
    (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)



  • 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



  • @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.



  • 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.


Log in to reply