Previously, we ran a background worker, that continuously goes through the list of configured apps, and checks whether there's a process running that we can attach to.
(Ignoring the "AttachMode" setting for now, assuming the default of "FindOrCreate").
There's a couple issues with this:
If we manually close an attached program, WTQ will immediately start a new instance, which may not be what we want;
If the starting of a new process doesn't succeed, we can end up in an infinite loop of creating new processes.
A known case of the latter, is when Windows Terminal is configured as the default console host, and we're trying to start an instance of PowerShell. WTQ may look for conhost.exe, but it will be gone, as the window has been taken over by Windows Terminal, usually as a tab. This results in an infinite loop of adding tabs to Windows Terminal, where WTQ thinks the process failed to start.
This PR changes the behavior, such that attaching to a process (which can include starting one) is done in response to specific events. Namely, when a hot key is pressed, and when WTQ starts.
Previously, we ran a background worker, that continuously goes through the list of configured apps, and checks whether there's a process running that we can attach to.
(Ignoring the "AttachMode" setting for now, assuming the default of "FindOrCreate").
There's a couple issues with this:
A known case of the latter, is when Windows Terminal is configured as the default console host, and we're trying to start an instance of PowerShell. WTQ may look for conhost.exe, but it will be gone, as the window has been taken over by Windows Terminal, usually as a tab. This results in an infinite loop of adding tabs to Windows Terminal, where WTQ thinks the process failed to start.
This PR changes the behavior, such that attaching to a process (which can include starting one) is done in response to specific events. Namely, when a hot key is pressed, and when WTQ starts.