When started via AutoHotKey, WT is unfocused. #12294

@vefatica commented on GitHub (Jan 30, 2021):

I also tried #Enter:: and #>Enter:: (I don't have a left Win key). Both resulted in WT having focus.

@vefatica commented on GitHub (Jan 30, 2021): I also tried `#Enter::` and `#>Enter::` (I don't have a left Win key). Both resulted in WT having focus.

claunia commented

@vefatica commented on GitHub (Jan 30, 2021):

But I must have had trouble with focus because several of my key/action definitions contain the line

WinActivate Program Manager ; desktop

Adding that to the #Enter script (before starting WT) may solve the problem.

@vefatica commented on GitHub (Jan 30, 2021): But I must have had trouble with focus because several of my key/action definitions contain the line `WinActivate Program Manager ; desktop` Adding that to the #Enter script (before starting WT) may solve the problem.

claunia commented

@djsavvy commented on GitHub (Jan 31, 2021):

Wow, thank you @vefatica! Adding that line right before the Run, wt did the trick!

It's not perfect --- if I open two terminal windows in succession and close the second from the keyboard, the focus doesn't go to the first (as you'd expect). But this is an edge case for sure! Thanks for giving me help with the common case.

@djsavvy commented on GitHub (Jan 31, 2021): Wow, thank you @vefatica! Adding that line right before the `Run, wt` did the trick! It's not perfect --- if I open two terminal windows in succession and close the second from the keyboard, the focus doesn't go to the first (as you'd expect). But this is an edge case for sure! Thanks for giving me help with the common case.

claunia commented

@djsavvy commented on GitHub (Jan 31, 2021):

I'm going to close this for now, since @vefatica came through with a workaround (thanks again!); if someone else has this issue they can re-open or open a new one.

@djsavvy commented on GitHub (Jan 31, 2021): I'm going to close this for now, since @vefatica came through with a workaround (thanks again!); if someone else has this issue they can re-open or open a new one.

claunia commented

@vefatica commented on GitHub (Jan 31, 2021):

I'm glad it helped.

Funny ... mine worked OK without that line. And when I put that line in mine, I did not have the edge case you described.

@vefatica commented on GitHub (Jan 31, 2021): I'm glad it helped. Funny ... mine worked OK without that line. And when I put that line in mine, I did not have the edge case you described.

claunia commented

@djsavvy commented on GitHub (Jan 31, 2021):

Unfortunately it seems like that line only helps some of the time. I tested it a bunch, and it was working 100% at first, but it's inconsistent now.

This is kinda frustrating.

@djsavvy commented on GitHub (Jan 31, 2021): Unfortunately it seems like that line only helps some of the time. I tested it a bunch, and it was working 100% at first, but it's inconsistent now. This is kinda frustrating.

claunia commented

@vefatica commented on GitHub (Jan 31, 2021):

Focus-stealing has never been a problem here. So I have customized a setting to make taking focus easy (because DevEnv has a hard time bringing Firefox to the foreground to show help). Perhaps it will help you. The setting is

HKEY_CURRENT_USER\Control Panel\Desktop ... REG_DWORD ... ForegroundLockTimeout

I set it to 0.

The default value is 200000 (0x30D40).

@vefatica commented on GitHub (Jan 31, 2021): Focus-stealing has never been a problem here. So I have customized a setting to make taking focus easy (because DevEnv has a hard time bringing Firefox to the foreground to show help). Perhaps it will help you. The setting is HKEY_CURRENT_USER\Control Panel\Desktop ... REG_DWORD ... ForegroundLockTimeout I set it to 0. The default value is 200000 (0x30D40).

claunia commented

@zadjii-msft commented on GitHub (Feb 1, 2021):

I'm not sure if there's anything actionable for us to do here. We're not doing anything bizarre like if (launched from AHK) { defocusTheWindow(); }. IMO this sounds like something that AHK would need to figure out on their side.

It kinda reminds me of #4233 (I know there's another, better issue tracking that problem but I can't find it right now).

I was looking around through AHK's documentation last week and found that there was a command to force setting a window to the foreground. Maybe you could use that to manually bring the terminal window to the foreground? Disclaimer: I don't really have any experience with AHK.

It sounds like what you're looking for is something like #653? That might be coming... sooner than previously expected...

@zadjii-msft commented on GitHub (Feb 1, 2021): I'm not sure if there's anything actionable for us to do here. We're not doing anything bizarre like `if (launched from AHK) { defocusTheWindow(); }`. IMO this sounds like something that AHK would need to figure out on their side. It kinda reminds me of #4233 (I know there's another, better issue tracking that problem but I can't find it right now). I was looking around through AHK's documentation last week and found that there was a command to _force_ setting a window to the foreground. Maybe you could use that to manually bring the terminal window to the foreground? _Disclaimer: I don't really have any experience with AHK_. It _sounds_ like what you're looking for is something like #653? That might be coming... sooner than previously expected...

claunia commented

@vefatica commented on GitHub (Feb 2, 2021):

I think @zadjii-msft might be referring to AHK's WinActivate command. You might try it after a slight delay, perhaps ...

Run wt.exe
Sleep, 300
WinActivate, ahk_class CASCADIA_HOSTING_WINDOW_CLASS

Setting the variable #WinActivateForce might enhance the WinActivate command.

@vefatica commented on GitHub (Feb 2, 2021): I think @zadjii-msft might be referring to AHK's `WinActivate` command. You might try it after a slight delay, perhaps ... ``` Run wt.exe Sleep, 300 WinActivate, ahk_class CASCADIA_HOSTING_WINDOW_CLASS ``` Setting the variable `#WinActivateForce` might enhance the WinActivate command.

claunia commented

2026-01-31 03:11:34 +00:00

@zadjii-msft commented on GitHub (Feb 2, 2021):

That's the one, thanks!

@zadjii-msft commented on GitHub (Feb 2, 2021): That's the one, thanks!

claunia commented

@ghost commented on GitHub (Feb 6, 2021):

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost commented on GitHub (Feb 6, 2021): This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for **4 days**. It will be closed if no further activity occurs **within 3 days of this comment**.

claunia commented

2026-01-31 03:11:34 +00:00

@djsavvy commented on GitHub (Feb 7, 2021):

Thank you so much @vefatica and @zadjii-msft!

I clean-reinstalled windows, which didn't fix the problem. When I tried the sleep+WinActivate method, the wrong WT window was getting focused at times. Setting the registry key alone didn't work consistently.

I think the combination of the two methods did the trick, though (at least the problem is very rare, if it's still there).

I'm still really curious about the root cause of the problem.

By the way, are there any potential negative effects of setting that registry key?

@djsavvy commented on GitHub (Feb 7, 2021): Thank you so much @vefatica and @zadjii-msft! I clean-reinstalled windows, which didn't fix the problem. When I tried the sleep+WinActivate method, the wrong WT window was getting focused at times. Setting the registry key alone didn't work consistently. I think the combination of the two methods did the trick, though (at least the problem is very rare, if it's still there). I'm still really curious about the root cause of the problem. By the way, are there any potential negative effects of setting that registry key?

claunia commented

2026-01-31 03:11:34 +00:00

@vefatica commented on GitHub (Feb 7, 2021):

By the way, are there any potential negative effects of setting that registry key?

I never quite understood what the big deal about focus-stealing was all about. That key is part of a mechanism by which Windows makes it difficult to "steal" focus. So I suppose setting that registry value could have a negative effect, namely, something steals focus when you didn't want it to do so. I must say, that never happens here.

@vefatica commented on GitHub (Feb 7, 2021): > By the way, are there any potential negative effects of setting that registry key? I never quite understood what the big deal about focus-stealing was all about. That key is part of a mechanism by which Windows makes it difficult to "steal" focus. So I suppose setting that registry value could have a negative effect, namely, something steals focus when you didn't want it to do so. I must say, that never happens here.

claunia commented

@zadjii-msft commented on GitHub (Feb 8, 2021):

Frankly, I have no idea what the reg key does. With these obscure user32 things, I trust there's a good reason they exist, even if I don't know what that is.

It's entirely possible that the root cause of this is a weird interaction between AHK and Xaml Islands. No way to be sure. There aren't all that many other applications using XI, so this might "only" affect the Terminal, when really it affects all XI apps. That's all conjecture though.

That being said, since you've found a workaround, I'm not sure there's anything else actionable from us here, so I'm gonna close this. Thanks!

@zadjii-msft commented on GitHub (Feb 8, 2021): Frankly, I have no idea what the reg key does. With these obscure user32 things, I trust there's a good reason they exist, even if I don't know what that is. It's entirely possible that the root cause of this is a weird interaction between AHK and Xaml Islands. No way to be sure. There aren't all that many other applications using XI, so this might "only" affect the Terminal, when really it affects all XI apps. That's all conjecture though. That being said, since you've found a workaround, I'm not sure there's anything else actionable from us here, so I'm gonna close this. Thanks!

claunia commented

@schmitmd commented on GitHub (Feb 15, 2021):

I hate to dead-thread bump, but I think I should include this as additional context. I've been using AHK to open up the regular wsl terminal to Ubuntu for quite a while using the following AHK script (opens with Win+o):

#o::
Run,ubuntu2004.exe,,,PID
WinWait ahk_pid %PID%
WinActivate, ahk_pid %PID%

This:

Always opens up a new Ubuntu WSL Terminal (including when there's an existing one)
Changes focus to it immediately regardless of existing focus being anywhere else (including another WSL window).

The same code however, doesn't show the same behavior with Windows Terminal. With WinTerm (i.e. replacing line 2 with Run,wt.exe,,,PID ),if there's an existing window, it will not open up a new one. If I remove the WinWait, it'll open up a new one, but not switch focus to the newly-created window. I'm wondering if this has to do with the fact that WinTerm is kinda-sorta-a-UWP-app,-but-not-really-because-it's-supposed-to-launch-like-a-traditional-application...? If I'm seeing things correctly with Window Spy in AHK, it looks like the app starts really fast with a different ahk_pid and then spawns another, which is the one I actually want for WinActivate. I'm guessing it has to do with tabs/panes/etc versus a sort of "main" WinTerm process but I don't know how I'd snatch the child pid properly or if there's a better way.. Not sure if this is ultimately an AHK issue or a Windows Terminal issue. Anyway, the above code might help someone if they're still on the regular WSL terminal and want the above 2 behaviors every time.

@schmitmd commented on GitHub (Feb 15, 2021): I hate to dead-thread bump, but I think I should include this as additional context. I've been using AHK to open up the regular wsl terminal to Ubuntu for quite a while using the following AHK script (opens with Win+o): ``` #o:: Run,ubuntu2004.exe,,,PID WinWait ahk_pid %PID% WinActivate, ahk_pid %PID% ``` This: 1) Always opens up a new Ubuntu WSL Terminal (including when there's an existing one) 2) Changes focus to it immediately regardless of existing focus being anywhere else (including another WSL window). The same code however, doesn't show the same behavior with Windows Terminal. With WinTerm (i.e. replacing line 2 with `Run,wt.exe,,,PID` ),if there's an existing window, it will not open up a new one. If I remove the WinWait, it'll open up a new one, but not switch focus to the newly-created window. I'm wondering if this has to do with the fact that WinTerm is kinda-sorta-a-UWP-app,-but-not-really-because-it's-supposed-to-launch-like-a-traditional-application...? If I'm seeing things correctly with Window Spy in AHK, it looks like the app starts really fast with a different ahk_pid and then spawns another, which is the one I actually want for WinActivate. I'm guessing it has to do with tabs/panes/etc versus a sort of "main" WinTerm process but I don't know how I'd snatch the child pid properly or if there's a better way.. Not sure if this is ultimately an AHK issue or a Windows Terminal issue. Anyway, the above code might help someone if they're still on the regular WSL terminal and want the above 2 behaviors every time.

claunia commented

@doubleOZ commented on GitHub (Oct 26, 2021):

I skimmed through, not sure if there was a proper answer but I was having trouble myself with opening terminal using win + t with autohotkeys. Completely new to it but have always used a lot of non-custom system shortcuts. based on some of the answers saying other shortcuts worked for them made me look to see if windows has a default win + t shortcut and they do. iirc it places focus on the taskbar.

tldr: disable the win + t shortcut in regedit, the interfering default windows shortcut should be disabled after a system reboot.

@doubleOZ commented on GitHub (Oct 26, 2021): I skimmed through, not sure if there was a proper answer but I was having trouble myself with opening terminal using win + t with autohotkeys. Completely new to it but have always used a lot of non-custom system shortcuts. based on some of the answers saying other shortcuts worked for them made me look to see if windows has a default win + t shortcut and they do. iirc it places focus on the taskbar. tldr: disable the win + t shortcut in regedit, the interfering default windows shortcut should be disabled after a system reboot.

claunia commented

@zadjii-msft commented on GitHub (Oct 26, 2021):

@doubleOZ If you're using AHK just to focus the Terminal window, then you may be interested in the globalSummon action

@zadjii-msft commented on GitHub (Oct 26, 2021): @doubleOZ If you're using AHK just to focus the Terminal window, then you may be interested in the [`globalSummon`](https://docs.microsoft.com/en-us/windows/terminal/customize-settings/actions#global-commands) action

claunia commented