LAUNCH launcher defines command line for the windows application process to start (like windows shortcut) and then, after it launches application process, it tries to find window created by application and place it inside of current workspace. In the effort to find a window it makes up to five identical search attempts. Each attempt of search for the application window goes for 1 second. It is looking for the window whose class and title should match "Window Class Regex" and "Window Title Regex" patterns given in the LAUNCH launcher config dialog. It is looking for the window that was created after application process was launched. Search first tries to find any matching window that belongs to launched process, then for any matching window that belongs to the group of the processes that is created by launched process, then it looks for any matching window that was created after process was launched. Search attempts are repeated until window is found or until there were 5 unsuccessful search attempts.
While search is in progress (up to 5 seconds - 5 attempts by one second each), LAUNCH launcher is still executing and another launcher cannot be executed until those 5 seconds have passed. In the normal situation window is found faster, it rarely takes 5 seconds to find window. 5 second are here just in case, if the process is taking long time to initialize itself before it creates its window. So, small delay should not be an issue when the window is expected to be created and captured. But in the situations where application process started by LAUNCH launcher should not create any window (and we know this in advance), this 5 seconds of the search (that will fail anyway) create unnecessary delay before next launcher can be executed. Particular example is starting Autohotkey script via LAUNCH launcher. Most often Autohotkey script will simulate user's typing and clicking but will not create any windows of its own. In this case, we cannot start second Autohotkey script sooner than 5 seconds after starting first Autohotkey script.
To avoid unnecessary delay in the situations where no window should be captured into workspace after launching application process, I have added new checkmark "Capture Application Window Into Workspace" to LAUNCH launcher configuration dialog.
LAUNCH Launcher new config dialog
When "Capture Application Window Into Workspace" checkmark is unchecked, search for application window is not performed and "Window Class Regex" and "Window Title Regex" patterns are ignored. When "Capture Application Window Into Workspace" checkmark is checked, search for application window is performed as before.
VIEWER launcher is special front-end for the LAUNCH launcher. It uses LAUNCH launcher facility under the hood. It has special table (ViewerDefinition.xml) that defines command line of application process and window capturing regex patterns based on extension of the local file that is configured in the VIEWER launcher or based on protocol in the URL that is configured in the VIEWER launcher. Once those parameters (command line and regex patterns for LAUNCH) are defined, VIEWER launcher simply executes LAUNCH launcher under the hood. It is similar to Microsoft Windows where certain file extensions are associated with certain applications that are used to open such files by default. For example, user can associate .ahk Autohotkey file extension with command line 'AutoHotkeyU32.exe' via ViewerDefinition.xml table. In such case execution of VIEWER launcher will build LAUNCH launcher command line by appending name/path of AutoHotkey .ahk file to the command line 'AutoHotkeyU32.exe' (application and file name are separated by a space). As a result 'AutoHotkeyU32.exe "ahk-file"' command line will be executed in internal LAUNCH and standard 5 second search for the application window will be initiated. To avoid unnecessary search, I have added extra column "CaptureWindowIntoWorkspace" (Y/N) to the ViewerDefinition.xml table. Value of "CaptureWindowIntoWorkspace" in the ViewerDefinition.xml table propagated into "Capture Application Window Into Workspace" LAUNCH setting when LAUNCH launcher is executed internally after translating VIEWER launcher configuration.
There is another property of VIEWER launcher: if it refers to local file, this local file will be exported/imported together with XML LauncherTree. This property did not change, it is only mentioned here for the sake of completeness.
In order to be able to pass identities of multiple windows from "proxy32 workspace and window manager" to AutoHotkey scripts via command line, new substitution parameter <PROXYHANDLESOFNONMINIMIZEDWINDOWS> was introduced. <PROXYHANDLESOFNONMINIMIZEDWINDOWS> is replaced in any launcher by the list of unsigned decimal numbers where each number identifies handle of Proxy32 non-minimized window in the current workspace. Identities in the list are separated from each other by space character.
Following dialog is invoked by pressing "Insert new parameter/password" button in the LAUNCH launcher configuration dialog shown above.
New substitution parameter <PROXYHANDLESOFNONMINIMIZEDWINDOWS>
New substitution parameter <PROXYHANDLESOFNONMINIMIZEDWINDOWS> is highlighted on the picture above. Pressing "OK" button in this dialog will insert substitution parameter <PROXYHANDLESOFNONMINIMIZEDWINDOWS> into command line text field of LAUNCH launcher (in the cursor position).
Sample Tree.xml (that is loaded after Proxy32 installation when user does not have any Tree.xml yet) was updated by adding sample AutoHotkey script that loops through the list of window handles given to it on the command line and sends "pwd" command to each window.
Script command line (in LAUNCH launcher) is:
AutoHotkeyU32.exe .\gui\ahk\type_pwd_to_all_non_minimized_windows_in_the_workspace.ahk <PROXYHANDLESOFNONMINIMIZEDWINDOWS>and the text of the script type_pwd_to_all_non_minimized_windows_in_the_workspace.ahk is shown below:
;to be started in LAUNCH launcher with the following command line: "AutoHotkeyU32.exe .\gui\ahk\type_pwd_to_all_non_minimized_windows_in_the_workspace.ahk <PROXYHANDLESOFNONMINIMIZEDWINDOWS>"
Loop %0% ; For each window handle passed as command line parameter.
{
MyWindowHandle := %A_Index% ; next window handle from command line
Sleep, 1000 ;1 second
ControlClick,,ahk_id %MyWindowHandle% ;click on window to make it active.
Send,pwd{Enter} ;send keypresses to active window
}
On execution, script walks one-by-one through all non-minimized windows in current workspace. It activates next non-minimized window in the workspace and then types 'pwd' command into it. It stops when all non-minimized windows in the current workspace have been processed.
Added new dialog to assign actions to Mouse shortcuts.
"Mouse Actions List" new dialog
Also added new button (with the picture of computer mouse) to workspace menu bar to invoke new dialog:
New workspace menubar button to invoke "Mouse Actions List" Dialog
Also added commands to several menu's to invoke new dialog:
New Menu entries to invoke "Mouse Actions List" Dialog
Removed Options Dialog page that was used before to assign actions to Mouse shortcuts.
Dialogs "Assign actions to Mouse shortcuts" and "Assign actions to hotkeys" can now be re-sized by user. In particular, they can be expanded to "full screen" mode. Full screen mode can make it easier to edit 150 mouse shortcuts assignments or 150 hotkey assignments.
Re-wrote all re-sizing code for all launcher configuration edit dialogs (for all 11 launcher types) to make re-sizing of those dialogs smoother.
Added two new assignable Mouse/Hotkey actions and renamed one existing action:
New actions:- EDIT_MOUSE_ACTIONS_DEFINITIONS - invokes Dialog "Assign actions to Mouse shortcuts"
- OPEN_HELP_FILE - opens help file in Microsoft help viewer
- TOGGLE_MENU_BAR_IN_THE_MAIN_WINDOW - used to be called SHOW_MENU_BAR_IN_THE_MAIN_WINDOW
Fixed "color is not displayed as configured" issue with tooltip windows created by OS for proxy32 GUI controls. I had to disable "Theme" for each of those OS-created tooltip windows to make them obey proxy32 tooltip color settings.
Updated terminology and reformatted texts for most of the proxy32 GUI control tooltips.