I use mobaxterm to connect from windows to a vncserver session on linux.
I works fine for some time, but then Ctrl key seems to be locked.
Thus normal typing become impossible, e.g. typing q sends instead Ctrl-q.
(After reconnecting to the same session, it works a again, for a while).
Is there a fix to unlock Ctrl or even prevent this behaviour?
I found that pressing the Ctrl+Alt+Del button
with the mouse stops locking the ctrl key.
Then one has to cancel the request to exit the session. This is at least more convenient than making a reconnection to the vnc session.
Related
I have connected IntelliJ to a remote JVM, and would now like to disconnect from the remote JVM without the remote JVM stopping. In Eclipse there are two buttons that explicitly stop the JVM or disconnect from the JVM, but the buttons on the debug windows in IntelliJ aren't clear. The tooltips and the online help aren't much help.
Stop (red square) - "Click this button to terminate the current process externally by means of the standard shutdown script."
Close (red X) - "Click this button to close the selected tab of the Run tool window and terminate the current process."
Rerun (green arrow around a grey square) - "Click this button to stop the current application and run it again"
I'm pretty sure it's the Stop button, but none of them makes it clear what will happen to the remote JVM.
Which button should I press to safely end the debugging session without killing the remote JVM?
Press the big red stop button (debug panel, on the left). It'll stop the debugger, not the remote process. I don't think you can use the debugger to explicitly kill the remote process -- you're only connected to the debug port and I don't think it can do things like that, unless you deliberately execute a System.exit(0) command in one of the code evaluation windows.
In my case I was looking for the red stop button which was not visible. But I found it on the left side of the debug window when hoovering over a blank section. Perhaps a bug since I am using color scheme Darcula?
Ctrl-F2 also works.
My application has a check box that gets checked using 'Shift' key. When I fired 'Ctrl + F', another short cut in my application, using Selenium Web Driver, the check box got checked automatically. However it worked fine when I used 'Ctrl + f'. This indicates that Shift is getting pressed by web driver inherently.
When I manually pressed Ctrl+Shift+f, the check box did not get checked. Can some one please explain what could be happening behind the scenes?
If you have used the Shift key in another test that has run before the one you are talking about, the Shift key will remain active until you sent the Keys.Null key.
I recommend sending the Keys.Null key before every test to ensure no modifierkeys remain pressed.
So I've used AutoHotKey to disable the AppsKey (the button on the keyboard which brings up the right-click menu). But I thought I could put it to better to use, and am trying to get it so that while I'm holding down the AppsKey the computer thinks I'm holding down Shift & Control instead.
I've been reading through the Command List but can't see anything for AppsKey down & up. Would anyone be able to share anything to enable me to do this?
Thanks
I don't understand what your problems are, but this little piece of code works for me:
AppsKey::Send, {SHIFT down}{CTRL down}
AppsKey up::Send, {CTRL up}{SHIFT up}
As you can see, there is an AppsKey up. Down on the other hand doesn't exist for hotkeys. In this example, the first hotkey triggers when AppsKey is pressed (that is, it triggers as soon as you hit it). The second hotkey triggers when it is released.
I moved to Lion 2 months ago, and since then I sometimes encounter that a TextMate keyboard shortcut doesn't work anymore (which means: nothing happens), and then, after a restart of TextMate, it works again.
This time, it was CTRL + ALT + SHIFT + DOWN, which should trigger Cucumber's Go to current step command. After restart of TM, it worked again. I also experienced this with CMD+SHIFT+7 (which results in Cmd-/ on my swiss layout) for commenting out lines.
Any idea about what's the problem? As I mentioned in a previous post, for the commenting out shortcut it finally happened to be the application Skitch sometimes which blocks this commend and prevents it from being sent to TM. But this doesn't have to do with the restart scenario I have now.
Anyway, it would be nice to have OSX display some info box whenever a keyboard shortcut is pressed which tells what exactly was executed, so e.g. when pressing CMD+S it would tell "Save Document", or CMD+SHIFT+3 "Take Screenshot", etc., so you'd always know what was triggered and don't have to think a shortcut ended up in Nirvana... Maybe there is some application or OSX extensions that does this?
I've found that when this happens, there's a background process going on that is, for some reason, disabling some or all of your keyboard shortcuts. I also found that it's very easily remedied by typing Command-. (period) which tells TextMate to cancel the running background task.
Try it next time it happens and see if that doesn't at least ameliorate the problem. Fixing it would require figuring out what background task is getting wedged and either fixing or eliminating it.
During development i have observed that certain PDAs with Windows CE and possibly Windows Mobile too are sending the Enter key twice in the key pressed event thus i execute twice the code that lies under the control's key press event for the return button.
I suspect that this is a hardware bug and i would like to ask how you resolved it without changing your application logic.
Without changing the logic? You really can't (unless there is a hardware or firmware fix). I'd guess the simplest mechanism (that requires a logic change) is to treat two Enter keys or keypresses in a short period (say < 100ms) then ignore the second.
I don’t know if this will help but if you read the keyboard port Enter is seen as two bytes rather than one.
This happened to me too and it turned out it was because the "enable character repeat" option was enabled in control panel->keyboard. The default repeat delay was way too fast for the keypad that we used, so I just slowed it down and the problem went away.