Home & End (on numpad) not honored by text entry system. #70858

New Issue

Michael Jensen · 2019-10-16T00:33:46+02:00

Michael Jensen commented

2019-10-16 00:33:46 +02:00

System Information

Operating system: Windows 10

Blender Version

Broken: 2.80

Description of the problem:

In Windows (all the way back to DOS 5.0, actually), when you turn numlock off, Home (7), End (1), Page Up (9), and Page Down (3) are all treated the same as the breakout keys above the arrows (additionally, 4, 8, 6, and 2 are treated as Left, Up, Right, and Down respectively). Literally every other text editor (or application that allows text entry) on Windows honors this keymap (again, when num lock is turned off).

Blender does not use standard OS widgets or dialogs, and in what I can only assume is an oversight, these keys are not correctly honored. It makes using the text editor and many of the text input dialogs difficult.

This is standard text-input functionality on Windows, and I believe it is broken in Blender.

Exact steps for others to reproduce the error:

Scenario 1

File->Save
Click the filename or path, and press the HOME key on the numpad (with numlock turned off)
Notice that nothing happens.

Scenario 2

Open any text editor window, prompt, or dialog,
Press HOME (SHIFT+HOME, or CTRL+SHIFT+HOME) on the numpad (with numlock off).
Notice again that nothing happens.

Scenario 3

Open the Add-ons menu, scroll to the bottom
Press Home on the numpad (with numlock off)
Notice that it does not scroll up.
Press Home above the arrow keys, notice that it does scroll up to the top.
(Any other UI on Windows would have treated the key presses as identical, most of them navigating to the top; e.g. in this Chrome Window, Home and End are honored correctly.)

Additional Info / Other thoughts

As a workaround, you can create extra key bindings for SOME of the missing functionality, but you can't do it for everything -- unless I'm missing something, but many of the dialogs (e.g. renaming an object, saving a file, etc.) do not appear to have their keybindings configurable.

The text editor is remappable, but even then you end up with 20+ extra keybindings that need to be manually configured; and the keybindings read incorrectly (e.g. it says Numpad 7, instead of Numpad Home* -- though it does honor that numlock must be on for it to work); and again, they still don't work in dialogs (e.g. file->save, rename an object, etc.).

(*: To clarify: even though they occupy the same physical key, they should not be treated as the same logical key for text input scenarios on Windows; Numpad Home/End, etc. must be treated exactly like the regular Home/End, etc. when Numlock is off).

### System Information Operating system: Windows 10 ### Blender Version Broken: 2.80 ### Description of the problem: In Windows (all the way back to DOS 5.0, actually), when you turn numlock off, Home (7), End (1), Page Up (9), and Page Down (3) are all treated the same as the breakout keys above the arrows (additionally, 4, 8, 6, and 2 are treated as Left, Up, Right, and Down respectively). Literally every other text editor (or application that allows text entry) on Windows honors this keymap (again, when num lock is turned off). Blender does not use standard OS widgets or dialogs, and in what I can only assume is an oversight, these keys are not correctly honored. It makes using the text editor and many of the text input dialogs difficult. This is standard text-input functionality on Windows, and I believe it is broken in Blender. ### Exact steps for others to reproduce the error: **Scenario 1** - File->Save - Click the filename or path, and press the HOME key on the numpad (with numlock turned off) - Notice that nothing happens. **Scenario 2** - Open any text editor window, prompt, or dialog, - Press HOME (SHIFT+HOME, or CTRL+SHIFT+HOME) on the numpad (with numlock off). - Notice again that nothing happens. **Scenario 3** - Open the Add-ons menu, scroll to the bottom - Press Home on the numpad (with numlock off) - Notice that it does not scroll up. - Press Home above the arrow keys, notice that it does scroll up to the top. - (Any other UI on Windows would have treated the key presses as identical, most of them navigating to the top; e.g. in this Chrome Window, Home and End are honored correctly.) ### Additional Info / Other thoughts As a workaround, you can create extra key bindings for SOME of the missing functionality, but you can't do it for everything -- unless I'm missing something, but many of the dialogs (e.g. renaming an object, saving a file, etc.) do not appear to have their keybindings configurable. The text editor is remappable, but even then you end up with 20+ extra keybindings that need to be manually configured; and the keybindings read incorrectly (e.g. it says Numpad 7, instead of Numpad Home* -- though it does honor that numlock must be on for it to work); and again, they still don't work in dialogs (e.g. file->save, rename an object, etc.). (*: To clarify: even though they occupy the same physical key, they should not be treated as the same logical key for text input scenarios on Windows; Numpad Home/End, etc. must be treated exactly like the regular Home/End, etc. when Numlock is off).

Michael Jensen commented

2019-10-16 00:33:46 +02:00

Added subscriber: @BrainSlugs83