I've noticed that if I'm using multiple panes, that if I switch focus from one tab to the other and then back again, that the keyboard focus won't follow it back. All keypresses seem to stay stuck in the 2nd pane unless I disconnect and reconnect the first one. This doesn't appear limited to when the pane is connected to a session either, as it often stops me from typing a server name to connect to unless I close the tab and reopen it.

I'm not able to replicate this (just switched back and forth between panes and keyboard focus follows). Can you post specific step-by-step instructions? Such as...

1. Opened RD Tabs.
2. typed in first server name
3. hit connect
4. opened new tab in new tab pane
5. typed...

etc.?

That would help me greatly in debugging this! It wouldn't surprise me if I neglected to catch a particular instance for trapping and sending keyboard focus. That's one of the trickiest things with Microsoft's RDP library!

Open RD Tabs
Create 2nd pane
Connect to server in 1st pane
Connect to server in 2nd pane
While 2nd pane is still connecting, begin typing in 1st pane
When 2nd pane connects it steals focus
Keyboard input no longer works in current tab in 1st pane, no problem with any new or existing tabs in the 1st pane

Sometimes the keyboard starts working again, but I haven't been able to reproduce it reliably. Running 2.0.12 if it helps.

Thanks.

Good catch. If "automatically steal focus" in the connections options IS checked, you can click back and it immediately works. If it is NOT checked, that's when it gets all confused (shouldn't be happening at ALL without that checked). After clicking back and forth a couple times, I got it to correctly have the input focus selected again, but I can see how this is incredibly annoying. I must have missed a "steal focus" trigger somewhere because this only happens if you are using multiple panes. In other words, it behaves as expected when you have a single pane and multiple tabs open. I'm pretty far through 2.1, so I think I'm going to hold off issuing a bug fix here for 2.0, but I may change my mind if it looks simple to fix. 🙂 Some of the re-wiring for multiple floating tab panes might make me re-invent the wheel for 2.1 if I issue a fix now, and I don't want to do that since my RD Tabs time is limited for a few months.

However, I CAN replicate this issue and a bug fix WILL be released, even if it is not immediate. Thanks for the catch!

I fixed this (I think) but it required extensive rewiring in the guts of how RD Tabs handles keyboard and mouse focus for the remote desktop -- which is more complicated than it looks on the surface. SOooo give it a good whirl in the 2.1 alpha which I will be posting in the other thread about 2.1 alpha very soon.