I have an MSI laptop, and whenever I want to press the letter 'e' it doesn't work. Only when I press another key and right after I press the key 'e' it works. I tried reinstalling the keyboard driver, restart, even tried going to safe mode and it still didn't work. I opened the key on the keyboard and its whole and not broken. Is it a software problem or do I need to buy a new keyboard?
Related
I'm using Xubuntu. When I start jshell in the terminal, I doesn't recognize when I press the enter key. Every other key gets detected normaly. Any suggestions how to fix that?
Solution for laptop users without an number pad on their keyboard:
Plug in an extra keyboard with a number-pad.
Start jshell, try to press enter on your laptop keyboard.
If it still doesn't work: On the extra keyboard: press "Num" key with which you activate the number pad.
Now pressing enter on your laptop keyboard again.
It should work now, otherwise turn the numberpad off and on again and repeat step 4.
Don't know why it works that way, but it does.
Write the following in your terminal:
numlockx on
Now it will work. To make this permanent, let Xubuntu execute this after booting.
In using AutoHotKey to block access to ALL keys, all keyboard shortcuts do stop working and the windows key on its own can be blocked i.e.
LWin::Return
RWin::Return
also all other keyboard shortcuts are blocked, however windows + L seems to operate on a higher level and works regardless.
I'm not sure if Autohotkey actually can disable the win+L combination, but it can be done through the registry. Here are detailed instructions: How to Disable the Lock Screen Shortcut Key (Win + L) in Windows.
To summarize:
In the registry editor, navigate to this key: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies.
Add a new key, "System", in "Policies".
In your newly created "System" key, add a new "DWORD (32-bit) Value".
Name the value “DisableLockWorkstation” and set its value data to "1".
Log off/on or restart.
Note that I haven't verified if this works. Also note that the linked instructions also includes steps to disable all WinKey combos if that is your desire.
I've got some AutoHotKey scripts that I use to move windows around my monitors. for example, I have [Shift]+[Win]+[Up] set to move the current window to the monitor above the current one ans size proportionally
My problem is that, since upgrading to windows 10 on Friday, executing one of these functions still performs its hotkey action, but then when I release the Shift key while still holding Window, the start menu opens. When I was still on 7, the start menu would only open if I pressed and released the Window key without pressing any other keys.
I don't have this problem with my hotkeys that use Control+Window instead of Shift. It's only when I press and release the Shift key while holding Window.
How can I fix this?
If your hotkey sends any keys other than LWin/RWin, that should suppress the Start menu. For example, Send {Blind}{vkFF}.
If it fails to suppress the Start menu, that most likely means the Win key is being released (virtually or physically) before you send the key, or released and pressed again after you send the key, and is not being masked correctly. You can troubleshoot this by using KeyHistory, which should show a Win-down immediately followed by a Win-up, and should indicate whether these events were generated by AutoHotkey and with what timing.
The Start menu should appear only if you press and release a Win key while not holding any other modifier keys, and without pressing or releasing any other keys. In other words, what you describe should not be possible unless your hotkey is directly or indirectly releasing Shift and pressing and/or releasing the Win key (and Send is failing to mask it).
Recent versions of AutoHotkey do not mask the Win key when used in hotkeys like +#Up::, because the presence of the Shift key has already masked it.
I have used DevC++ and similar environments also have this application. While the overwrite mode is on the code overwrites instead of code moving to right.
The issue can be solved by using fn + insert(print screen) in Windows 8 or above and insert key in lower versions.
Like #Kokul says, you can press the Insert Key. If your Windows machine does not have a physical Insert key, you can press the virtual one, which you can find by pressing:
Windows Key > Ease of Access Keyboard Settings > Use the On-Screen Keyboard
Then press the Insert key which is located on the virtual keyboard to the right of the Enter key. Pressing the virtual key will behave like pressing the physical Insert Key.
I understand that new keyboards can be ordered online, but now that this problem has proven to be hard I am completely fascinated by it.
Many old laptop keyboards as they wear develop consistent shorts which cause multiple keys to react when a single key is pressed. For example, on my little sister's computer if you press "r" the system outputs "vr", "i" outputs ",i" and so-on.
Assuming the user is not a vim/emacs power user, the keyboard still seems salvageable. It seems that if the keyboard driver was changed so that pressing the "r" key resulted in the computer accepting "backspace r" the "v" would disappear and not be such a hassle anymore.
Xmodmap XKB and other systems seem to assume that each single key depression will result in a single command. Does anybody understand the missing link where more than one character can come from a single keypress? There seem to be many places in the stack where this can be pulled off, but none of them are particularly clearly documented. Another fun fact is that you can't force this in the ubuntu keyboard shortcuts editor, ubuntu will stop you from entering the changes there under the premise that "this will make it impossible to type."
Hacking around in xev shows that the computer believes that when you hit and release 'r' that it gets a keypress event for 'v' then a keypress event for 'r' then a keyrelease event for 'v' then one for 'r'. If you could change the configuration to ignore a first keypress if there is no corresponding key release before the next key is pressed, that would work too.