When Application is in background, clicking on terminal session should bring application to front, not just focus app.

[GoogleCodeExporter]

Since We wrap PuTTY in a Windows form we are unable to detect the click
event on the terminal window itself, however clicking anywhere else will
bring the application to the foreground as you would expect. 

To do this properly it will require an unmanaged DLL written in c++ (or c)
that we can capture the global mouse events for the embedded window with. A
P/Invoke call that captures the windows events and marshals the data back
and forth between the application. 

Not difficult, but also not trivial, its on the Wish List and I'll likely
work on this after I get some cleanup done and some general project
housekeeping.

Original issue reported on code.google.com by jimradford@gmail.com on 10 Aug 2009 at 7:52

[GoogleCodeExporter]

Would it be possible to take PuTTY itself and make it a component.  The source 
code
is already available but I'm not sure how difficult it would be to turn into a 
component.

Original comment by jasonh...@gmail.com on 7 May 2010 at 8:19

[GoogleCodeExporter]

The truth is: once you start working at the source code level, you have to 
support it and I am pretty sure this is best left to the Putty developers 
themselves...

Original comment by avrl...@gmail.com on 17 Jun 2010 at 9:58

[GoogleCodeExporter]

I recently switched to superputty from puttycm. This was the number one issue 
that was bugging me. So I fixed it, patch is attached. I found this forum post 
which had a good solution for hooking into system wide events:
http://social.msdn.microsoft.com/Forums/en-US/clr/thread/c04e343f-f2e7-469a-8a54
-48ca84f78c28

I'm not a .net/C# coder, so I kept my changes to a minimum and put them at the 
top of the ctlApplicationPanel.cs.  I'm sure you'll want to organize it better. 

Also this is setting up a hook per instance of ctlApplicationPanel.cs, it would 
probably be better to set the hook up once and monitor hwnds for all terminal 
windows, but I wasn't sure where would be best to do that. 

I think with just a little bit more polish superputty could easily be the best 
tabbed ssh client for windows and gain a lot more users. It always seems tabbed 
clients come out and quickly lose steam without every quite being finished.

Original comment by gromp...@gmail.com on 25 Sep 2010 at 5:01

Attachments:

• ctlApplicationPanel.cs.patch

[GoogleCodeExporter]

Fixed via fix from #68 (didn't see this patch).
v1.2.0.3

Original comment by btatey...@gmail.com on 29 Apr 2012 at 12:51

• Changed state: Fixed

[GoogleCodeExporter]

I just downloaded v1.2.0.4 and for me the issue is not fixed (Windows XP using 
Kitty instead of Putty).

Original comment by breker.c...@gmail.com on 2 May 2012 at 1:56

[GoogleCodeExporter]

will try w/kitty this weekend and try to replicate.

Original comment by btatey...@gmail.com on 3 May 2012 at 3:31

[GoogleCodeExporter]

It works somewhat using Windows 7 64bit, Kitty or Putty doesn't make a 
difference.

For me the behaviour is the following: When another program window partially 
obscures the SuperPutty window and I click into a terminal window SuperPutty is 
brought to front. So far it's ok. But then to restore the window which 
beforehand obscured SuperPutty I have to click 2 times on it's icon in the task 
bar. I tested with 1.2.0.6.

As said before, using XP (which I have to use at work) the behaviour has not 
changed at all.

Original comment by breker.c...@gmail.com on 9 May 2012 at 8:34

[GoogleCodeExporter]

yeah, the behavior is b/c I'm using BringToFront() which doesn't activate the 
form.

i've tried a few variations on activate/bringtofront, etc. nothing works quite 
right.

Original comment by btatey...@gmail.com on 14 May 2012 at 1:25

• Changed state: Accepted

[GoogleCodeExporter]

patch in #3 has same problem.

Original comment by btatey...@gmail.com on 14 May 2012 at 11:07

[GoogleCodeExporter]

I experimented a little with the solution from comment #3. Instead of 

>             if (eventType == EVENT_SYSTEM_FOREGROUND && hwnd == m_AppWin)
>             {
>                 // This is the easiest way I found to get the superputty 
window to be brought to the top
>                 // if you leave TopMost = true; then the window will always 
be on top.
>                 this.TopLevelControl.FindForm().TopMost = true;
>                 this.TopLevelControl.FindForm().TopMost = false;
>             }

I used

              if (eventType == EVENT_SYSTEM_FOREGROUND && hwnd == m_AppWin)
              {
                  // Send press of Alt key so that the main window can be activated w/o user interaction
                  keybd_event(VK_MENU, 0xb8, 0, 0);
                  // Activate main window
                  MainForm.Activate();
                  // Release Alt key
                  keybd_event(VK_MENU, 0xb8, KEYEVENTF_KEYUP, 0);

                  // Set foreground back to terminal window
                  SetForegroundWindow(m_AppWin);
              }

Of course one has to avoid to get into an endless loop when SetForegroundWindow 
is called programatically. This works fine in XP and 7.

Original comment by breker.c...@gmail.com on 14 May 2012 at 3:10

[GoogleCodeExporter]

Nice.

Will give it a try.

Original comment by btatey...@gmail.com on 14 May 2012 at 10:47

[GoogleCodeExporter]

I can confirm that the issue is fixed in 1.2.0.8 running on XP. I will test in 
Win 7 this evening at home.

Original comment by breker.c...@gmail.com on 21 May 2012 at 10:46

[GoogleCodeExporter]

Hi,

I am using 1.4.0.1. 
I experience this exact issue:
When I am working in a superputty session, if I start doing something outside 
of superputty (browsing/email/whatever), I need to click twice on the session 
again to get back to that same sessions.

2012-12-10 15:28:30,213 DEBUG        frmSuperPutty - [262892] Activated
2012-12-10 15:28:35,839 INFO  EventWindowActivator - [181536404] Activating 
Main Window - 
current=(C:\Users\Sean\Downloads\SuperPutty-1.4.0.1\SuperPutty-1.4.0.1\SuperPutt
y.exe)
2012-12-10 15:28:35,862 INFO      ApplicationPanel - [181536404] ReFocusPuTTY - 
puttyTab=shops2, caller=WinEventProc-FG, AltTab=False, result=True
2012-12-10 15:28:35,905 DEBUG        frmSuperPutty - [262892] Activated
2012-12-10 15:28:35,988 INFO      ApplicationPanel - [852020] ReFocusPuTTY - 
puttyTab=shops4, caller=SHELLHOOK, result=True

IN this instance, I was working in shops2 then i moved away, when I moved back 
(looking at logs) superputty clearly knows i'm clicking on shops2 (as it's 
before the shops4 in log) but FocusActivator moves it to shops4.

I have tried all the different activator plugins in the dropdown menu but none 
of them seem to work.

Any ideas? Am I making sense?

Original comment by she...@gmail.com on 10 Dec 2012 at 3:30

[GoogleCodeExporter]

When moving between sessions that are part of the main superputty window (where 
the file/view/tools/help are etc.), i can see in the DEBUG logger that the 
caller is ActiveDocumentChanged, which would appear to be some variable 
tracking the active document.
When I click on a session that i've 'dragged out' of the main window, it 
doesn't change the ActiveDocument, it just refocuses it (i think) and caller is 
equal to WinEventProc-FG.
The problem is, when I'm working in the 'dragged-out' session, and i click 
somewhere outside of superputty entirely, once I click back into my 
'dragged-out' session, it then refocuses automatically into the Active Document 
(which is really annoying as then i have to click again to get back).

2012-12-10 15:48:37,621 INFO  EventWindowActivator - [181536404] Activating 
Main Window - 
current=(C:\Users\Sean\Downloads\SuperPutty-1.4.0.1\SuperPutty-1.4.0.1\SuperPutt
y.exe)
2012-12-10 15:48:37,643 INFO      ApplicationPanel - [181536404] ReFocusPuTTY - 
puttyTab=shops2, caller=WinEventProc-FG, AltTab=False, result=True
2012-12-10 15:48:37,655 DEBUG        frmSuperPutty - [262892] Activated
2012-12-10 15:48:37,738 INFO      ApplicationPanel - [852020] ReFocusPuTTY - 
puttyTab=shops4, caller=SHELLHOOK, result=True

(you can see if refocusing in the above log excerpt)

i hope i am explaining myself.

Original comment by she...@gmail.com on 10 Dec 2012 at 3:49

[GoogleCodeExporter]

Could I ask that if you implement this to make it configurable. I don't want to 
raise the window when focusing on it as I use X mouse set-up. Thanks

Original comment by vinylte...@gmail.com on 3 Jan 2013 at 4:19

[GoogleCodeExporter]

Hey folks,

Any news on that issue?
When fix will be provided?

Original comment by airgunster on 18 Mar 2013 at 12:49

[GoogleCodeExporter]

sheggs - the key is the floating window...i'll see what i can do.

vinyltears...sure, i can all a null handler which will allow you to turn off 
the focus junk

airgunster...did you have a specific issue/bug like sheggs or is it just not 
working for you?  Unfortunately, making the superputty and putty window rise on 
the click is an involved process.  I've tried several methods and none of them 
seem to work across the board.  

Original comment by btatey...@gmail.com on 19 Mar 2013 at 11:16

[GoogleCodeExporter]

Hi,

btatey...@gmail.com,
Yes, I have the same issue as sheggs.

Original comment by airgunster on 27 Mar 2013 at 7:18

[GoogleCodeExporter]

I'm guessing this is related, but can certainly open another issue (or find the 
appropriate one)...

In 1.4.0.3, docked tabs, when switching tabs with CTRL+TAB the focus remains in 
the original tab, even though the cursor in the new tab may appear to have 
focus.

I've attached a snippet of the log showing the focus failing.

Original comment by gcli...@gmail.com on 29 Apr 2013 at 4:42

Attachments:

• superputty_log.txt