[Feature Request] add option to put focus on an app when already running
schmurtzm opened this issue · comments
Hi,
A checkbox "Put focus if already running" could be very useful.
Most of the users shortcuts are probably using clavier+ to run programs, so when you launch a shortcut of an app which is already running there are 2 possible behaviors :
- if the app allow only one instance -> the app will come in front with focus
- if the app allow multiple instance -> the app will open a new instance, it means a new windows which sometime is not the desired behavior .
Real-life example :
My shortcut to run notepad++ is perfect , it runs it and if it is already running the app comes in front with focus.
On the other hand my OneNote shortcut will launch one new window of OneNote each time (and I can't force only one instance).
Thank you.
I don't think it's possible to implement this in a general manner. As far as I know there is no standard mechanism to figure out if a given window is the already-running manifestation of a given command-line.
I can think of heuristics that work sometimes but not always. For instance, a shortcut that opens file X with Notepad++ should execute the command-line even if Notepad++ is already launched but for a different file Y.
Clavier+ could instead leave it up to the user to identify the window to activate, for instance with a command for "give the focus to the first window named X if one exists, else run command-line Y" i.e. a conditional combination of [{Focus,0,<window name>}] and [[<command line>]]. In the mean time you can achieve the same effect with a script and configure Clavier+ to associate a keyboard shortcut to that script (for instance with AppActivate and Execute in VBScript).
i.e. a conditional combination of [{Focus,0,}] and [[]]
I'll like it. Seems to be a killer feature from my point of view.
Adding a helper for the user find the right name of his window could be nice too (like the target you have done for "Programme actif" but it returns the name of the selected window instead of the name of the executable.
By the way I think that the field name "write text" doesn't reflect the power of this field which allows special commands.
In the mean time you can achieve the same effect with a script and configure Clavier+ to associate a keyboard shortcut to that script (for instance with AppActivate and Execute in VBScript).
I already do that currently with an autohotkey script from my own. But I don't like it due to the time needed to find the window (sometimes it takes 2 seconds ... doesn't seems but it's long for a shortcut 😅 ).
Here my script which show the logic that I use currently :
; Passer 2 paramètres au script :
; 1 - le path du logiciel à lancer
; 2 - une partie du nom de la Windows à trouver pour voir si le logiciel est déjà lancé ou non
; Exemple : myscript.ahk "C:\Program Files\Mozilla Firefox\firefox.exe" " - Mozilla"
SetTitleMatchMode, 2 ; permet de baser WinActivate sur une partie du nom
ProcessPath=%1%
SplitPath, ProcessPath , ProcessName,
;msgbox %ProcessName%
WindowName=%2%
Process, Exist, %ProcessName% ; check to see if TimeLeft is running
{
If ! errorLevel
{
IfExist, %ProcessPath%
Run,%ProcessPath%
else
;MsgBox, ,FocusLauncher , App not found, 3
TrayTip , FocusLauncher, App not found, 5000, 1
sleep, 5000
Return
}
else
{
;Process, Close, %ErrorLevel%
WinActivate ,%WindowName%,
WinGet, CalcIDs, List, %WindowName% ; -> ne fonctionne pas sous Win 10 avec une fenetre minimised
; manip pour Win10 : si minimisé on met le focus sur le thread enfant : https://autohotkey.com/boards/viewtopic.php?t=43997
;If (CalcIDs = 1) ; Calc is NOT minimized
; CalcID := CalcIDs1
;else
; CalcID := CalcIDs2 ; Calc is Minimized use 2nd ID
;winActivate, ahk_id %CalcID%
;msgbox %WindowName%
}
}
ReturnAdded a [{FocusOrLaunch,<window name>,<delay>,<command>}] command to the beta version: http://utilfr42.free.fr/dn/beta/Clavier.exe
If [{FocusOrLaunch}] finds the window, it behaves like [{Focus,0,<window name>}] (no delay). Else, it behaves like [[<command>]][{Focus,<delay>}]
I still need to support comma escaping, test thoroughly, and update the documentation.
I like it so much , it is very fast ! Really thank you for the awesome support you make on your app !
Some remarks about the beta :
- Little bug : I have to duplicate all my "\" in <command> otherwise these are skipped
- bug ? : it is not possible to run a Windows 10 app with <command> (it opens explorer.exe)
- Remark : Still in <command>, quotes are indispensable to manage paths with spaces
- Remark : it not easy for the user to find the right window title, sometimes even in task manager it is not the right title. On window 10 the right title is displayed in the tooltip which appear on mouse over in the taskbar (power user will use something like AU3_Spy.exe). This detail could be documented :
Working example of use of the beta with onenote :
[{FocusOrLaunch,* - OneNote for Windows 10,,"C:\\Users\\username\\AppData\\Roaming\\Microsoft\\Windows\\Start Menu\\OneNote for Windows 10.lnk"}]
Just figured out that there is a bug on Focus and FocusOrLaunch on Windows 10 : you can't retrieve the focus on the window if it is minimized (the behavior is different on older versions of Windows, so there was no problem).
This is the same bug I encountered on my autoIT script above and I've adopted this solution (it seems that Windows creates a second hwnd for apps when you minimize it)
Do you want a dedicated issue for this one or is it OK here ?
Little bug : I have to duplicate all my "\" in otherwise these are skipped
This is intended and documented. The same applies to [[...]]. Clavier+ has escaping limitations/quirks/bugs that I'm working on fixing (for instance escaping commas is sometimes not possible, and escaping sometimes requires two \ instead of just one), but simple cases such as \\ in commands should work fine.
bug ? : it is not possible to run a Windows 10 app with <command> (it opens explorer.exe)
Works for me (with proper escaping).
Still in <command>, quotes are indispensable to manage paths with spaces
As expected. Quotes are necessary to disambiguate.
it not easy for the user to find the right window title
It depends a lot on your version of Windows, how it's configured, and the specific windows. Many solutions out there and many caveats, I won't risk myself to make any recommendation.
you can't retrieve the focus on the window if it is minimized (the behavior is different on older versions of Windows, so there was no problem)
Interesting regression, thanks for noticing! That's easy to fix, the latest beta should behave correctly.
This is intended and documented. The same applies to
[[...]]. Clavier+ has escaping limitations/quirks/bugs that I'm working on fixing (for instance escaping commas is sometimes not possible, and escaping sometimes requires two\instead of just one), but simple cases such as\\in commands should work fine.
woops, I miss this part of the documentation ;)
bug ? : it is not possible to run a Windows 10 app with (it opens explorer.exe)
Works for me (with proper escaping).
OK I got it , example for Onenote :
[{FocusOrLaunch,* - OneNote for Windows 10,,"explorer.exe" "shell:appsFolder\\Microsoft.Office.OneNote_8wekyb3d8bbwe!microsoft.onenoteim"}]
It depends a lot on your version of Windows, how it's configured, and the specific windows. Many solutions out there and many caveats, I won't risk myself to make any recommendation.
You're probably right... and may some users will take a look inside issues 😅
you can't retrieve the focus on the window if it is minimized (the behavior is different on older versions of Windows, so there was no problem)
Interesting regression, thanks for noticing! That's easy to fix, the latest beta should behave correctly.
I've just tested the last beta, it seems already solved, thank you !
It seems it's almost done for this one 😉 I like so much using it !
I found no new bugs and updated the beta version with 2 tweaks:
- Reordered the arguments of
[{FocusOrLaunch}]to make the delay entirely optional and self-document that Clavier+ applies the delay after executing the command, contrary to[{Focus}]. The new syntax is:[{FocusOrLaunch,window name,command,delay}] - Simplified the escaping syntax for edge cases such as
[{Focus,0,\!Warning!}](no longer[{Focus,0,\\!Warning!}]). It's technically a breaking change, but I don't think many users will be impacted, if at all.
Strangely my commands was still working before modifying it... Anyway the new syntax is OK for me.
It is already a daily habit to use FocusOrLaunch, I can't go back anymore 😉
[{FocusOrLaunch}] implemented in e2d7d35, released in version 11.2.0.