Community
    • Login

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

    Scheduled Pinned Locked Moved General Discussion
    8 Posts 3 Posters 3.5k Views 2 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • John LiudrJ Offline
      John Liudr
      last edited by

      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.

      PeterJonesP 2 Replies Last reply Reply Quote 0
      • PeterJonesP Online
        PeterJones @John Liudr
        last edited by

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

        1 Reply Last reply Reply Quote 2
        • John LiudrJ Offline
          John Liudr
          last edited by

          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.

          1 Reply Last reply Reply Quote 0
          • Terry RT Offline
            Terry R
            last edited by

            @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

            1 Reply Last reply Reply Quote 2
            • PeterJonesP Online
              PeterJones @John Liudr
              last edited by 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
              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)

              1 Reply Last reply Reply Quote 5
              • John LiudrJ Offline
                John Liudr
                last edited by

                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

                PeterJonesP 1 Reply Last reply Reply Quote 1
                • PeterJonesP Online
                  PeterJones @John Liudr
                  last edited by

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

                  1 Reply Last reply Reply Quote 2
                  • John LiudrJ Offline
                    John Liudr
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 1

                    Hello! It looks like you're interested in this conversation, but you don't have an account yet.

                    Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

                    With your input, this post could be even better 💗

                    Register Login
                    • First post
                      Last post
                    The Community of users of the Notepad++ text editor.
                    Powered by NodeBB | Contributors