Group Separators (GS) ASCII 0x1D are not correctly detected when entered from Barcode-Scanner

[anhaupt2]

Group Separators (GS) ASCII 0x1D are not correctly detected when entered from Barcode-Scanner

With Version 8.6.5 Windows x64 Notepad++ will detect Group Seperators (GS) ASCII character 0x1D falsely as TAB character.
When I read a Data Matrix Code containing Group Seperator characters with a barcode scanner (elmicron CR1411) those characters are detected wrongly.

The screenshot illustrates the issue.

The content of the upper line was generated by inputting into notepad++ 8.5.1. There Group-Separators as well as Record-Seperators, and End-Of-Transmission characters are correctly displayed.

The content of the lower line was generated by inputting into notepad++ 8.6.5. There Group-Separators as now wrongly displayed as TABs where as Record-Seperators and End-Of-Transmission characters are still correctly displayed.

To me it seems that something got broken with keyboard input. The pseudo keyboard we use is a handheld barcode scanner (elmicron CR1411).

Text containing Groups-Seperators inserted via Copy&Paste is displayed correctly. Its only displayed wrongly when entered from barcode scanner.

Steps to Reproduce the Issue

1. Open a new text file
2. Scan the sample barcode from the image attached with an barcode scanner (probably any model supporting DMCs)

Expected Behavior

Group Separators are read and displayed as GS

Actual Behavior

Group Separators are read and displayed as TABs

Debug Information

Notepad++ v8.6.5 (64-bit)
Build time : Mar 29 2024 - 17:04:43
Path : C:\Program Files\Notepad++\notepad++.exe
Command Line :
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
Periodic Backup : ON
OS Name : Windows 11 Enterprise (64-bit
OS Version : 22H2
OS Build : 22621.3296
Current ANSI codepage : 1252
Plugins :
JsonTools (5.6)
mimeTools (3.1)
NppConverter (4.6)
NppExport (0.4)
XMLTools (3.1.1.13)

[alankilborn]

Since those that could look into this are not likely to have the barcode scanner, it might help if you could isolate which exact version change caused the problem to appear. There's a lot of changes between 8.5.1 and 8.6.5.

[xomx]

@anhaupt2
Cannot reproduce, I see similar result with the GS-chars in my N++ (v8.6.5 x64, Win10), no TAB-substitutions there.
Try to disable your v8.6.5 plugins one by one...

Here is what I decoded from your pic and used for the testing in N++:
#1496_-_sample_pic_decoded_and_pasted_into_NPP.txt

[anhaupt2]

I finally found out, that I was wrong and that it's not a bug introduced by some specific Notepad++ Version.
Rather it is the Group Separator is wrongly detected as TAB charachter if Num-Lock ist turned off on the PC keyboard.
So the Group separator (GS) is correctly detected if NumLock is ON.
The GS is detected as TAB if NumLock is OFF.
This is the case for versions 8.5.1 and 8.6.5 and probably for all npp versions.
One could argue if GS should get recognized correctly independently of NumLock turned ON or OFF.

[alankilborn]

Rather it is the Group Separator is wrongly detected as TAB charachter if Num-Lock ist turned off on the PC keyboard.

That's a very interesting find!

[xomx]

@anhaupt2
?!
This has nothing to do with the N++ but probably with some program/plugin you are using to decode that pic.
I can of course paste the same decoded data to N++ with that NumLock OFF and still have the same GS-chars there.
Please close this issue.

[anhaupt2]

I'm not talking about using Copy and Paste. Copy and Paste will always work regardless of NumLock being ON or OFF. Paste is just two Key-Events to Notepad++ namingly Ctrl and V. What I'm talking about is using an USB-Barecode-Scanner which is functioning as second physical keybord. When you scan the barcode with the scanner you get a lot more Key-Events than just Ctrl-Key and V-Key. It's a different scenario. The behavior is as follows. You turn off NumLock OFF on you primary (PC) keybord and you scan the barcode with the secondary Barcode-Scanner-keyboard. Then you get TABs instead of GS. If you turn ON NumLock on your primary keyboard you get the GS. It not possible to emulate the issue with Copy and Paste.

btw I have removed all plugins from Notepad++. So no plugin should be interfering.

And all this might indeed be some Windows OS peculiarity. Somehow the key press events received from the barcode scanner are different with NumLook turn ON/OFF. So yes may be it's not an issue off n++.

[xomx]

@anhaupt2

I'm not talking about using Copy and Paste.

I know, I read your 1st post thoroughly. I only demonstrated that the N++ itself does not mangle that GS-chars.

So yes may be it's not an issue off n++.

Yes - that is what I tried to say to you. I would like to help but I cannot debug this issue without having that specific HW. It looks to me as a device or driver issue. Or it is a Win problem as you have already said (does this HW use its own SW/drivers or a common Windows ones?).

Did you tried the same with some other app than N++? (This way we can at least definitely rule out that this is a problem with the N++.)

[anhaupt2]

With the barcode canner there is no special device driver involved beside the standard windows device drivers: "USB Input Devive" and "HID Keyboard Device". Also I don't know of any "reference" software that shows the same bahavior as there is rarely any software I know thats capable of capturing the ASCII control characters comming from a keyboard. Most software just filters out this control characters. For my part I will close the issue as I don't want to invest more time into the matter. I know that I have to turn on NumLock to get the characters right into n++.

[alankilborn]

I don't know of any "reference" software that shows the same behavior as there is rarely any software I know that is capable of capturing the ASCII control characters coming from a keyboard

You could try the Scintilla demo editor: https://www.scintilla.org/SciTEDownload.html

[anhaupt2]

I can confirm that Scintilla does read the GS correctly both with NumLock turned ON and OFF.

[xomx]

I can confirm that Scintilla does read the GS correctly both with NumLock turned ON and OFF.

Interesting. So I will try some debugging (I will use 2nd usual USB keyboard for that) later.

What I know about the WinOS is that it cannot handle multiple keyboards separately. So when one attach another HID-device (USB-keyboard...), Win assigns to it the default (== currently active) keyboard mapping that you are using on that system. This can then do some strange stuff, e.g. when you press NumLock on one keyboard, it will also affect the state of the other one (if the two keyboards are compatible, it simply switches ON/OFF the NumLock state/led on both). So if your barcode scanner HW (virtual HID keyboard) is somehow incompatible with your computer's default keyboard mapping (different number/layout of keys), weird char-keycode changes may really occur...

But when you are saying that the SciTe editor has not the same problem as the N++ has, it is starting to be really weird^2.

[anhaupt2]

In an WPF-Application I'm working on I get a different sequence of PreviewKeyDown SystemKey events for GS characters depending on wether NumLock is On or OFF. In my application I just map both matching variants of SystemKey sequences to get the GS character. This somehow tastes like a workaround but it works for me. Maybe they are doing something similar in Scintilla. But maybe a clean solution would process the keyboard input on a lower level than I currently do.