[AHK] redirecting Windows Explorer to XY

Discuss and share scripts and script files...
Post Reply
autocart
Posts: 903
Joined: 26 Sep 2013 15:22

[AHK] redirecting Windows Explorer to XY

Post by autocart »

 CONTENTS

:!: INTRO
     How the Script Generally Works
     Config File
:ball: DOWNLOADS / :tup: CREDITS / :idea: CHANGE LOG
:cup: HOW TO CONTROL REDIRECTIONS
     Automatic Control of Redirection
     Manual Redirection
     Manual Escape of Redirection
:om: MORE SETTINGS
     Automatic Redirection at Scriptstart
     Manual Redirection from XY Back to WE
     XY Autostart
     Redirection to XY Read-Only Instances
     Autofocus of List in XY
     Zip and Other Files
     Temporary Script Suspension
:bug: KNOWN LIMITATIONS
 :beer: IDEAS FOR THE FUTURE


:!: INTRO

Hi all,
here is a script to redirect user specified windows of Windows Explorer (from now on called "WE") to tabs in XYplorer (from now on called "XY"). The script is written in AutoHotkey (AHK) and remote controls WE and XY regarding redirection.

The script was written for the following two scenarios:
  1. XY's setting "XY is default file manager" is not getting respected by some programs
    Despite XY's build-in optional functionality to act as the system's default file manager (XY menu Tools/Configuration/Other/Shell Integration), sometimes there still are WE windows opening instead of XY (e.g. from within certain 3rd-party-software or for other reasons).
     
  2. List items are not getting automatically selected in XY
    At other times XY *is* sucessfully used as the system's default file manager to open a folder (if that setting is on) but any list itmes which would normally be selected in WE do *not* get selected in XY (e.g. when clicking in Firefox in the "downloads" window on the "open containing folder" button).
 
How the Script Generally Works

For such scenarios, this script, if running in the system tray, catches any WE window that gets opened, reads the location and selected items shown in that WE window, and, if the user specified settings allow it, closes that WE window, opens a new tab in XY with that location, and selects any list items in XY that where selected in WE before (and scrolls them into view). If an XY tab with that location already exists, it is reused.
Hint:
For the script to work also in cases of scenario No. II, of course, the XY setting to act as the system's default file manager must be turned *off*.
The script will stay in the system tray until manually exited through the script's tray context menu.

Config File

Some of the scripts settings can be customized by the user. These settings are located in a separate config file. That config file is named "redirectWEwindowsToXY_v#.#.config.ahk", with "#.#" standing for the config file's version number, e.g. “4.1“. Each config file is compatible to all scripts who's version number starts with those same digits. However, a script file's version number may be longer.

There is a detailed explanation of the settings after the downloads and change log sections.

:ball: DOWNLOADS

Regarding the Available Downloads Below

I am purposely *not* offering a compiled exe version of the script. The download includes the editable ahk script file, the config file, an icon file that can be used as tray icon, and an url file pointing to the main Autohotkey download. The ahk and config files include this (and a bit more) documentation inside of them.

The reason why I am not offering compiled versions of the script is that I really don't want to promote downloading and running executables from some stranger on any forum (including me right here). This can be dangerous and such exe files should never be trusted. Besides, if there is something going wrong on the computer at the users end, then I want the user to be able to check and see (and me to be able to easily proof - protecting myself) that there was no malicious code in my script, which would not be possible, if I offered an already compiled exe.

Instead, I want to encourage everyone to download the AutoHotkey base program from here: https://www.autohotkey.com/download/ and run my "redirectWEwindowsToXY" ahk script, that is inside the downloadable zip, with that AutoHotkey program.

The AutoHotkey program offers two main usage options:
  1. It can be installed the traditional way using the "installer version". By default, ahk files are set to run when double clicking on them.
  2. It can be used to run ahk files as a portable version without a real installation. Do do so, download the ZIPPED Autohotkey version from the website above. Just unzip it and create a Windows shortcut to the included AutoHotkey.exe with the path to an ahk file as command line parameter inside the shortcut definition. Then run that shortcut.
If you want to use the icon in the download as system tray icon, just ensure that it stays in the same folder as the ahk file itself.

If you want a compiled version of an ahk file, it is really simple to compile it yourself: Download and install the AutoHotkey "installer version". Then right-click on the ahk file, that you want to compile, and choose "Compile Script" from the right-click menu. This will create a compiled exe of the ahk file in the same location. That's it. It is that simple.

And if you want to include an icon in the compiled exe, then - after installing the AutoHotkey program -, instead of right-clicking on the ahk script file, go to the start menu, choose the AutoHotkey folder and start the little helper app "Convert .ahk to .exe". In the dialog of that app, state the "Source (script file)", where to save the "Destination (.exe file)" and which "Custom Icon (.ico file)" to use. Click "> Convert <". Done.

Newest Version for Download

!! The code in the download is provided "AS IS". Usage is completely at your own risk. No warranties from my side. !!
For all script versions: Copyright by me: autocart (user name at the ahk and XYplorer forums) unless otherwise noted in the code. Regarding my code, I am just a hobby ahk programmer, so please don't be too critical with my coding style and mess, thank you.

vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv

redirectWEwindowsToXY_v4.2.1_210831.zip
(34.29 KiB) Downloaded 39 times

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Change log below.


Here are older versions:
redirectWEwindowsToXY_v4.1_200512.zip
(25.49 KiB) Downloaded 182 times
redirectWEwindowsToXY_v4.0_200501.zip
(24.58 KiB) Downloaded 90 times
redirectWEwindowsToXY_v3.4.1_200430.zip
(22.14 KiB) Downloaded 72 times
redirectWEwindowsToXY_v3.3_200428.zip
(21.11 KiB) Downloaded 81 times
redirectWEwindowsToXY_v3.2_200425.zip
(19.09 KiB) Downloaded 79 times
redirectWEwindowsToXY_v3.1_200424.zip
(13.91 KiB) Downloaded 74 times
redirectWEwindowsToXY_v3.0_200423.zip
(13.04 KiB) Downloaded 79 times

:tup: CREDITS

First of all, not all AHK code used in the script was written by me. I am specifically pointing out in the code itself, where I got it from if it was from someone else. Other than that, all the following cool people helped so far (as of 2021-08-30) with e.g. testing, bug fixing, suggestions and motivation, as can be seen in this forums thread.

binocular222
kiwichick
yusef88
Dustydog (Special thanks to Dustydog for motivating me to pick this baby back up after a couple of years! This also shows that posting to a year's old thread is not bad at all but can be very good.)
yuyu
1024mb
Keagel
kotlmg
gb007
hankr123
sovot29146
wfeg

:idea: CHANGE LOG

Code: Select all

Changes in version 4.2.1 - 210831:

-) The line 825 - WinWaitActive, ahk_id %vXYhWnd% - could have caused the redirection 
   to pause until XY was manually activated. I think I had it in previous versions and 
   wrongly readded it in in 4.2 again. Since the script seems to work better without the 
   line, I commented it out (again).

Changes in version 4.2 - 210831:

-) Added a tray menu item which activates or deactivates the hotkey for redirecting 
   XY tabs manually to WE, that is specified in the config file.
-) Added the variable vAutofocusListInXYAfterRedirection to the config file to specify 
   if the list in XY should automatically get focus after a redirection, in case some other 
   part of XY has focus at the time. This can be useful, because if the list does *not* have 
   focus, then any selected items might visually not be distinguishable so easily.
-) Added the variable vOpenRedirectedPathsInSeparateReadOnlyXYInstances to the 
   config file to specify whether redirected WE paths should be opened in separate (new) 
   XY read-only instances or in the normal XY window as new tab.
-) Added the variable vUseSeparateIniFileInCaseOfReadOnlyXYInstance in the config 
   file to specify a path to a separate ini file (e.g. for the layout) that should be used 
   for read-only XY instances. If left blank, the normal ini file is used.
-) The tray icon context menu can now be opened also with a single left mouse button 
   click on the tray icon. Before, the context menu opened only with a right mouse button 
   click.
-) Changed the indicator symbol in the tray menu for the suspended state from a check 
   mark to a big fat dot. This way it might be less confusing, since the meaning of the 
   other checkable items is slightly different, plus their logic is reverse too (check = 
   hotkeys are "on" but with the suspend item it means check = script is "off"). Just a 
   little tiny experiment. (FYI, other indicator symbols for the tray menu items are, it 
   seems, not available in standard AutoHotkey.)
-) If a hotkey is not defined, then the tray item context menu will still generate an 
   entry indicating that the hotkey could be defined but has not been. (BTW, the Ctrl-Hotkey 
   for manually avoiding redirection is, so far, hard coded / not user definable. Right now 
   it can be de-/activated but only through the tray icon context menu at runtime. However, 
   this is on the to-do list.)
-) Tried to improve the structure and the explanations in the config file a bit.
-) Internal change: Added StringReplace, path, path, file://, // to the function 
   Explorer_GetPath(hwnd=""), as suggested by gb007 
   (https://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=10671&start=75#p179211)
-) Internal change: Added quotes to the autorun-path of XY.
-) Internal change: Updated the XYmessenger functions.
-) Internal change: Changed how the red-S tray icon in suspended/deactivated state is 
   generated.

Changes in version 4.1 - 200512:

-) Added the variable vHotkeyInXYtabsToTriggerRedirectionToWE to the config file 
   to specify a hotkey to manually redirect a tab in XY to WE (which is the opposite 
   direction than usually). This hotkey only works in XY.
   It can be set to the same hotkey as vHotkeyInWEwindowsToTriggerRedirectionToXY is 
   set to, which only works in WE, so that the hotkey serves as kind of a toggle-hotkey 
   between XY and WE. (As suggested by Dustydog, see 
   https://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=10671&p=178249#p178248)
   In case that a view in XY does not have a real path (e.g. "My Computer" or XY paper 
   folders), WE for now always opens with the "My Computer" view.
-) Added the variable vCloseXYtabIfRedirectedToWE to the config file to specify 
   whether or not the XY tab should be closed if it is redirected to WE.
   In case that the view in XY does not have a real path, the XY tab is not closed, 
   regardless of this variable.
-) Internal change: Changed the function name ShellMessage_forCtrlWinE to 
   ShellMessage_keepTheNextWEwindow.

Changes in version 4.0 - 200501:

-) Moved the user customize section out into a separate .config.ahk file. (As suggested 
   by 1024mb, see https://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=10671&start=45#p177998)
   This helps the user to not have to update the user customizeation part of 
   the script each time a new version is released. Plus, it is easier to keep the 
   overview in a much shorter file without the distraction of the intro or the 
   main code below. The new .config.ahk file carries the first two digits of the 
   version number of the script version, which it belongs to, in its name, e.g. 
   “4.1“. The main version and/or the first sub-version number of the script 
   (and thus the name of the .config.ahk file) will from now on be incremented 
   only, if the compatibility of the .config.ahk file changes. When the script is 
   updated but the compatibility with the config file stays the same, only the 3rd 
   part of the script's version number will be incremented, e.g. “4.1.2“. (At first 
   I was about to increment only the script's main version number each time the 
   config file would change, but realized that there might still be a considerable 
   amount of new user settings to come?, so the chances that the main version 
   number would go up fast seemed to risky to me.)
-) Added a check for the script file's encoding and the encoding of the new config.ahk
   file. If they are not saved in the UTF-8 format with BOM, then the script will pop 
   a message box and refuse to run.
-) Added a global hotkey, specified in the variable 
   vHotkeyGlobalToSuspendUnsuspendTheWholeScript in the .config.ahk file, which will 
   suspend or unsuspend the script. (As suggested by Dustydog, see 
   https://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=10671&start=30#p177771)
-) Added a tray menu item which toggles the use of Ctrl to manually keep a WE 
   window (just in case).
-) Renamed the tray menu items a bit.

Changes in version 3.4.1 - 200430:

-) Fixed a bug with none-ascii characters.
   Saved the script file as with UTF-8 *with* BOM. Before it was saved as UTF-8 
   without BOM, which caused none-ascii characters to be processed incorrectly.

Changes in version 3.4 - 200429: (only bug fixes)

-) Maybe fixed that XY sometimes crashed when being autostarted. When XY was 
   autostarted it sometimges crashed, as it seems, without the line "WinWait, 
   XYplorer ahk_class ThunderRT6FormDC", which is strange to me because the 
   code before that line should have aleady made sure that the XY window exists. 
   However, it did not always crash. Re-added that line in for now, nevertheless. 
   So far, it never crashed on autostart with that line.
-) Fixed / Changed (hopefully improved) the way how paths, which are being 
   redirected to XY, are passed to XY. There could have been problems with how 
   paths were compared to the existing tabs. Especially if the redirected path was 
   a sub path of an existing tab, it would have not opened a new tab but changed 
   the current tab to the new path.
-) Fixed a bug by which the script would send XY into a scripting error, if the 
   redirected path contained single quote characters.
-) Fixed a bug that if a path was redirected to XY and the list in XY did *not* have 
   focus, then any selected items in WE would be selected in XY but not be scrolled 
   into view. Now they are (respectively the first selected item is).
-) Fixed a bug preventing to manually force redirect zip content views to XY.
-) Fixed / Changed the way how paths, that are really files (e.g zip files), are 
   handled when passed to XY. There was an inconsistency in the code how such 
   paths were handled, which could have led to XY displaying nothing in a new tab. 
   This was highly unlikely to surface to the user, but might have after the fix 
   above. Now, if the path is really a file, then the path to the parent directory of 
   that file is always taken as the redirected path and the file as selection.
   
Changes in version 3.3 - 200428:

-) Fixed some wrong logic in the processing of events. Previously, if XY was not 
   already running, it would be automatically started also if the WE window was to 
   be kept as WE window. In that scenario also, if no correct path to XYplorer.exe 
   was specified, then the script would still pop the corresponding message box and 
   wait for XY to be started manually. This made not even any sense, since the WE 
   window would anyway not be redirected to XY. This is changed now. The script 
   will only check for the open XY window and react accordingly if the WE window 
   is to be redirected.
-) Fixed a logical bug with RegEx compare: If hard coded keywords/paths were used 
   AND command line parameters AND RegEx was used as compare method, then 
   there was a logical bug which could have led to everything being a match (besides 
   the RegEx-exceptions)
-) Changed the order of the help text a bit. Adjusted the order of the variables in 
   the "USER CUSTOMIZE SECTION" of the code accordingly.
-) Added the variable vApplyRulesToExistingWEwindowsAtScriptStart to optionally 
   apply the specified rules also to existing WE windows at script start.
-) Added the variable vHotkeyInWEwindowsToTriggerRedirectionToXY to be able to 
   specify a hotkey to redirect WE windows to XY manually, if pressed while the 
   targeted WE window is active.
-) Simplified the system tray context menu to three items:
	(1) Toggle menu item to use/activate the specified hotkey for redirecting WE 
	    windows manually (or deactivate it).
	(2) Toggle menu item to Pause / Suspend Script which both pauses the script 
	    and suspends the hotkeys.
	(3) Fully exit the script.

Changes in version 3.2 - 200425:

-) Added code for an optional custom tray icon and supplied a simple icon with it.
-) Renamed the variables; especially the variable with all the keywords and paths is 
   now called vWindowsExplorerPaths.
-) Added the options/variables vKeepOrRedirect_matchingWEPaths, 
   vUseRegExForPathCompare and vExceptionPathsInCaseOfRegEx.
-) Added some visual marking of the user customize section in the code below
-) In case the variable vKeepOrRedirect_matchingWEPaths has an incorrect value, a 
   message box will pop.
-) Changed the hard coded behaviour of *not* redirecting the display of the content 
   of zip files to XY: 
   Now it is only hard coded for the case if RegEx is *not* used as compare method. If 
   RegEx is used, then the behaviour for zip files can be specified in the RegEx pattern.

Changes in version 3.1 - 200424:

-) Fixed the problem that the script would crash if XY was not active.
-) The path to XY can now be specified in the variable $pathToXYplorer at the beginning 
   of the code.
-) In case of an XY autostart process, a tooltip will be diplayed close to the mouse cursor.
-) In case the XY autostart process could not be started, a message box will pop.

Changes in version 3.0 - 200423:

-) Improved reliability:
   Before, the script sometimes missed WE windows or seemingly could not retrieve its 
   path and then did not react as expected.
-) Improved behaviour when paused:
   Now the script is respecting the script's paused state (see the script's system tray 
   context menu) in that it stops redirecting when the script paused. (As suggested by 
   Dustydog, see https://www.xyplorer.com/xyfc/viewtopic.php?f=7&t=10671&start=30#p177771)
   Before it ignored the state of being paused and redirected anyway.
-) Changed the behaviour of the script regarding already existing WE windows:
   In previous versions, when the title bar of already existing WE windows (which existed 
   prior to the scripts start) changed (e.g. when changing a folder in such a window or 
   when refreshing by hitting F5), then the script also used to redirect such WE windows 
   to XY. Not anymore. Now, if a WE window already exist at the scripts start, the script 
   leaves it untouched.
-) Added a Control-key-escape option:
   If the left or right Control key is pressed while a WE window opens, then this 
   particular WE window will *not* get redirected to XY.

:cup: HOW TO CONTROL REDIRECTIONS

There are WE windows that should not be redirected, e.g. control panel windows. Various users might also want to keep various other content inside WE, e.g. any special folders, for what reason ever. Thus, in order to have control over which WE windows should get redirected to XY and which should not, there are the following options:

Automatic Control of Redirection

The script allows to specify keywords and paths that are then compared with the location being displayed in a new WE window. That location typically amounts to the same as the content of the WE address bar, e.g. "Computer", "Libraries", "Pictures", etc., and actual paths. Based on the result of the comparision the script will either redirect the WE window to XY or not. Details in the next paragraphs.

The Compare Method

The method of how the keywords and paths are compared with the WE window's location can be specified in the setting vUseRegExForPathCompare. The setting can have one of the following two values:
  • "1": The RegEx (Regular Expressions) compare method is used. That means that RegEx patterns (PCRE flavor) can be used for specifying keywords and paths. This compare method is recommended due to its ability to formulate general patterns.
  • "0": The "identical" compare method is used. That means that one of the specified keywords or paths and the WE window's location must be identical to be a match.
Hint:
Regarding RegEx, here are some helpful sites for learning and formulating:
https://www.regular-expressions.info/quickstart.html
https://regex101.com/ (a testing environment)
Keywords and Paths

For specifying the keywords and paths themselves, the following two options for doing so are available:
  • They can be specified in the setting vWindowsExplorerPaths - each separated by "|" (pipe character).
  • They can be passed to the script as command line parameters - each separated by a space (and quoted if they contain spaces).
In both cases, any folder paths must be specified without trailing backslash. (The trailing backslash thing is on the to-do list, so that the user should not have to care about it anymore. However, it is harder to take care of it than one might think.)

Both options of specification *are* allowed together at the same time.

Example with command line parameters:
"path_to_autohotkey.exe" "path_to_script.ahk" Computer Libraries Pictures "C:\some kind of folder\another folder"
Hint:
In the config file there are some suggestions for keywords to be used on an English, German, and Spanish version of Windows.
Exceptions from General RegEx Patterns

If RegEx is used as a compare method, then the script also allows to specify exception patterns from the main patterns. Therefore, those main patterns can contain more general patterns and the exception patterns can take care of special exceptional cases. (Since this setting would not make any sense for the "identical" compare method, it is ignored in that case.)

These exception patterns can be specified in the setting vExceptionPathsInCaseOfRegEx. There is no option to feed them by command line. Of course, they also use RegEx syntax. Again, each exception must be separated by "|" (pipe character).

Choose Redirect or Keep

The user can specify whether all the matching new WE windows are redirected to XY or, otherwise, all the not matching ones are redirected. This is specified in the setting vKeepOrRedirect_matchingWEPaths. The setting can have one of the following two values:
  • "Redirect": All matching new WE windows *are* redirected. All not matching ones are *not* redirected.
  • "Keep": All matching new WE windows are *not* redirected (they are "kept" as they are). All not matching ones *are* redirected.
Manual Redirection

WE Windows that did not get redirected to XY can be redirected manually by force, so to speak. This is done by pressing a keyboard shortcut, aka "hotkey", while the source WE window is active. The user can specify the key combination for manual redirection in the setting vHotkeyInWEwindowsToTriggerRedirectionToXY. Details are given in the config file next to the setting.

The hotkey can be activated or deactivated on the fly in the script's system tray context menu by clicking on the applicable menu item. As a reminder, the corresponding menu item also shows which hotkey has been specified. If no such hotkey is specified, then the system tray context menu will contain an item indicating that the hotkey could be defined but has not been.
Hint:
Since the hotkeys for manual redirection (to XY) and for manual redirection from XY back to WE (see subheading "Manual Redirection from XY Back to WE") only work in their respective source applications, both hotkeys can be set to the same keyboard combination. This could save brain power.
Manual Escape of Redirection

Sometimes, the user might not want for indiviual WE windows to be redirected to XY that normally do get redirected. In such a case, the user can hold down the left or right control key while the desired WE window opens. Then, that one WE window will be left untouched by the script. Typically, the control key must be held down until the WE window is actually visible. If released too early, it might not work.

Example:
With the script running, pressing Win+E would open a new WE window which normally would get redirected to XY - of course, depending on the settings, but let's say that it would. Pressing Control+Win+E, the new WE window would *not* get redirected to XY. (Of course the control key escape option should work also if a WE window is opened by other means.)

This functionality of the control key can be activated or deactivated on the fly in the script's system tray context menu by clicking on the applicable menu item. The item also serves as a reminder that you can use the control key in such a way. Currently, there is no other way to deactivate it, e.g. in the config file, but it is on the to-do list.

:om: MORE SETTINGS

Automatic Redirection at Scriptstart

The script can apply automatic redirection also to all WE windows already existing at the moment of the script's start (not just to newly created ones while it is running in the background). This behavior can be activated in the setting vApplyRulesToExistingWEwindowsAtScriptStart. The setting can have one of the following two values:
  • "1": activated
  • "0": deactivated
Manual Redirection from XY Back to WE

Also XY tabs can be redirected to WE (the other direction than usual), but only manually. This is done by pressing a keyboard shortcut, aka "hotkey", while XY is active and the source tab is open. The user can specify the key combination for redirection in the setting vHotkeyInXYtabsToTriggerRedirectionToWE. Details are given in the config file next to the setting.

In case that a view in XY does not have a real path (e.g. "My Computer" or XY paper folders), WE for now always opens with the "My Computer" view.

The hotkey can be activated or deactivated on the fly in the script's system tray context menu by clicking on the applicable menu item. As a reminder, the corresponding menu item also shows which hotkey has been specified. If no such hotkey is specified, then the system tray context menu will contain an item indicating that the hotkey could be defined but has not been.
Hint:
Since the hotkeys for manual redirection (to XY) (see subheading "Manual Redirection") and for manual redirection from XY back to WE only work in their respective source applications, both hotkeys can be set to the same keyboard combination. This could save brain power.
Option to Close XY Tab

Additionally to redirecting XY tabs back to WE, the script can be told to close the tab in XY or not. This can be specified in the setting vCloseXYtabIfRedirectedToWE. The setting can have one of the following two values:
  • "1": Close the XY tab when redirected to WE
  • "0": Do not close the XY tab
However, in case that the view in XY does not have an existing path, the XY tab is not closed, regardless of this setting.

XY Autostart

If XY is not running it will be started automatically if the path to XYplorer.exe is specified correctly. The path can be specified in the setting vPathToXYplorerForAutostart. A tooltip close to the mouse cursor will indicate the starting process of XY. If the XY autostart should not work for some reason (e.g. if the wrong or no path is specified) the script will display a message box and wait for the user to start XY manually.

Redirection to XY Read-Only Instances

The following is more of an experimental feature to see if it is useful and if it gives users ideas for maybe other similar features.

Normally, the script redirects WE windows to the first found existing XY instance or else opens XY in a normal way. However, the script can be set to instead redirect WE windows each time to a new XY read-only instance (aka "throw away clone" - compare XY file menu > item "Open Throw Away Clone"). This feature can be activated in the setting vOpenRedirectedPathsInSeparateReadOnlyXYInstances. The setting can have one of the following two values:
  • "1": Use XY read-only instances for redirection
  • "0": Use first found XY or open in normal way
For this feature to work, the setting vPathToXYplorerForAutostart (see subheading "XY Autostart") must be pointing to a valid XYplorer.exe file.
Hint:
This feature can especially be beneficial with the setting to use a separate ini file in such a case (see below).
Remark:
Always opening a whole new XY instance will most likely be considerably slower than reusing an existing one. So, use with low expectations. An alternative idea could be to keep one dedicated XY instance (with or without a special ini file) always running just for the purpose of redirection. Feedback and ideas are welcome.
Separate Ini File for XY Read-Only Instances

When the script is set to use XY read-only instances for redirection it can also use a separate ini file to open these XY instances with. Thus these XY read-only instances can, e.g., have either a simplified or an especially complex layout - whatever one wants.

The name and path to this ini file can be specified in the setting vUseSeparateIniFileInCaseOfReadOnlyXYInstance. If the specified ini file does not exist or the setting is left blank, then the normal ini file is used also in read-only instances. More details are given in the config file next to the setting.

Autofocus of List in XY

Normally, it is not ensured that the list in XY will have focus after a redirection from WE. This can sometimes be annoying because it can be hard to distinguish the selected items when the list does not have focus. Therefore, in the setting vAutofocusListInXYAfterRedirection the script can be told to automatically focus the list in XY after a redirection from WE. The setting can have one of the following two values:
  • "1": Autofocus list after a redirection from WE
  • "0": Do not change focus in XY after a redirection from WE
Zip and Other Files

WE windows can show the content of a zip file, whereas XY cannot.

Therefore, if the "identical" compare method is used, WE windows that show the content of a zip file, are *not* automatically redirected to XY. They are kept as WE windows. Otherwise the content view of the zip file would be lost.

However, if RegEx is used as compare method, then the user must specify it manually in one of the RegEx patterns if he/she wants a zip file content view to be kept in WE (e.g. with \.zip$ either as part of a "keep pattern" or as part of an "exception to redirection pattern").

If (for any reason) any file path is redirected to XY (zip or any other file), then the XY tab is opened at the containing folder and the file is selected in the list.

Temporary Script Suspension

The whole script with all its functionality can be suspended/unsuspended in the script's system tray context menu and/or with a global keyboard shortcut, aka "hotkey". The user can specify the key combination for the global hotkey in the setting vHotkeyGlobalToSuspendUnsuspendTheWholeScript. Details are given in the config file next to the setting.

As a reminder, the corresponding menu item also shows which hotkey has been specified. If no such hotkey is specified, then the system tray context menu will contain an item indicating that the hotkey could be defined but has not been.

This hotkey cannot be deactivated on the fly, as can the hotkeys for manual redirection (to XY) and for redirection from XY to WE.

:bug: KNOWN LIMITATIONS

-) Whenever a WE window is "redirected" to XY, it will still open for a short moment in a normal way before it is closed again. For this script to work, I do not know of any way how to avoid that.
-) In case of multiple XY windows being open at the same time, the most recently active XY window will be used for redirection.
-) This script has not been tested with WE add-ons, which add tabs to WE.

 :beer: IDEAS FOR THE FUTURE

-) make a separate help/readme file
-) maybe handle also other message scenarios - not just "window created"
-) maybe re-introduce automatic redirection of existing WE windows while browsing the file system in that WE window. I think, this has pros and cons. The pros are that if I specifially browse to a path which I want to open in XY it will be done automatically. The cons are that if I browse to a path which gets redirected to XY, I might have forgotten to think of it and might not want that at this very moment. I think for now, the new hotkey feature with which it is possible to manually force-redirect the current path/view in an WE window to XY, might be the best solution. But I am open for suggestions.
-) improve the MsgBox popping when the WE path could not be determined (maybe with debug-information that a user could then post in the forum for my knowledge) and make it easier for the end user to disable that MsgBox if he/she would want to not see it
-) add a compatibility check for the found config file; in case it is not there or it is an old version, offer the user to create a new config file with default values.
-) adding to the throw away clone idea (read-only instance): implement a functionality to move the throw away clone window tab to a main XY window tab. and vice versa.
-) adding to the throw away clone idea: allow the user to specify, which WE windows get redirected to a throw away clone window in XY and which get redirected to the main XY window
-) Add an entry to the tray menu to open the config file in the default editor.
-) Make a GUI for the config options.
-) Make the Ctrl-Hotkey for manually avoiding redirection user definable. (Right now it can only be de-/activated through the tray icon context menu at runtime.)
-) Take the burden off the user to have to think of defining paths without trailing backslash.
-) Make reuse of already existing tabs optional.
-) In case that XY is already running, make the read-only option also work without having to specify the XYplorer.exe path.
-) Allow to specify the pane in XY to be used
-) ... to be continued ...

The list above are just brainstorming results and not a real roadmap, just saying. For any suggestions for improvement I am grateful (whether they are aleady included in the list above or not), because I want this script to be of help to many users. Many thanks in advance!
Last edited by autocart on 15 Sep 2021 00:28, edited 140 times in total.

binocular222
Posts: 1414
Joined: 04 Nov 2008 05:35
Location: Hanoi, Vietnam

Re: Redirecting win explorer windows to XYp [with AHK]

Post by binocular222 »

Do not use While 1.
Your script will execute constantly and stress the CPU.
Use ShellHook instead:

Code: Select all

DllCall( "RegisterShellHookWindow", UInt,WinExist() )
MsgNum := DllCall( "RegisterWindowMessage", Str,"SHELLHOOK" )
OnMessage( MsgNum, "ShellMessage" )
ShellMessage( wParam,lParam )
{
  If ( wParam = 1 AND WinActive("ahk_class CabinetWClass")) ;  1 means HSHELL_WINDOWCREATED
{
      Msgbox, Do something here
}
}
Return
Your script will be in dormant state and only fire whenever a new window is created. If it's Windows Explorer (ahk_class CabinetWClass), then do something.
<Note: SheelHook does not detect creation of child windows
I'm a casual coder using AHK language. All of my xys scripts:
http://www.xyplorer.com/xyfc/viewtopic. ... 243#p82488

autocart
Posts: 903
Joined: 26 Sep 2013 15:22

Re: Redirecting win explorer windows to XY [with AHK]

Post by autocart »

Thx, binocular222
I will try this out some time later, though.
So far it does not consume much CPU on my PC anyway.
But always good to know about alternatives. Thank you. :)

Edited the 1st post.
Last edited by autocart on 05 Apr 2020 00:13, edited 1 time in total.

kiwichick
Posts: 290
Joined: 08 Aug 2012 04:14

Re: [AHK] redirecting win explorer windows to XYp

Post by kiwichick »

Oh what a godsend this is!!! Unfortunately it doesn't work for me. I'm using the latest version of XYplorer on Windows 7 Home Premium 64-bit system. When I run the script I get this error:

Image

Is this fixable? Cheers.

autocart
Posts: 903
Joined: 26 Sep 2013 15:22

Re: [AHK] redirecting win explorer windows to XY

Post by autocart »

Did you use the whole code exactly as I pasted it or did you change something?
If u changed something can u post the whole code, please.
I admit that the code is far less then perfect. For anyone using it would not hurt to understand a little bit of autohotkey.
Last edited by autocart on 05 Apr 2020 00:13, edited 1 time in total.

yusef88
Posts: 960
Joined: 28 Jan 2013 03:50
Location: Windows 8.1 32-bit

Re: [AHK] redirecting win explorer windows to XYp

Post by yusef88 »

would you compile the script to exe ,please?

autocart
Posts: 903
Joined: 26 Sep 2013 15:22

Re: [AHK] redirecting win explorer windows to XY

Post by autocart »

yusef88 wrote:would you compile the script to exe ,please?
yusef, in order for this to make any sense, I would have to improve the code soo much. Right now you have to adapt it manually (as you can read in the comments of the code). If I make an exe then this is not possible anymore. Maybe I will invest the time to improve the code later but not now. If you install autohotkey, though, you can save the code as *.ahk file and run it this way.

But it is nice to see that there are people interested in my script. This makes is more likely that I will improve the script. It gives me more motivation. Let's see...
Last edited by autocart on 05 Apr 2020 00:14, edited 1 time in total.

kiwichick
Posts: 290
Joined: 08 Aug 2012 04:14

Re: [AHK] redirecting win explorer windows to XYp

Post by kiwichick »

autocart wrote:Did you use the whole code exactly as I pasted it or did you change something?
If u changed something can u post the whole code, please.
I admit that the code is far less then perfect. For anyone using it would not hurt to understand a little bit of autohotkey.
Thanks autocart, I changed "Adresse" to "Address" as you recommended but apart from that I used the code exactly as pasted. When it threw the error I changed the $XYpExe path because my XYplorer is portable but the same error. That is the only change I made. Is there a particular location I should place the script file (eg: XYplorer folder)? Is the script looking for XYplorer files somewhere other than the $XYpExe path?
Last edited by kiwichick on 04 May 2014 00:33, edited 1 time in total.

kiwichick
Posts: 290
Joined: 08 Aug 2012 04:14

Re: [AHK] redirecting win explorer windows to XYp

Post by kiwichick »

In case it matters I'm running:
Windows 7 Home Premium 64-bit
AutoHotkey v1.1.14.04
XYplorer v14.00.0100 (portable)

autocart
Posts: 903
Joined: 26 Sep 2013 15:22

Re: [AHK] redirecting win explorer windows to XY

Post by autocart »

updated the code in the first post
please tell me if it works
BTW: the $XYpExe varibable was not necessary, I deleted it
Last edited by autocart on 05 Apr 2020 00:14, edited 1 time in total.

kiwichick
Posts: 290
Joined: 08 Aug 2012 04:14

Re: [AHK] redirecting win explorer windows to XYp

Post by kiwichick »

autocart wrote:updated the code in the first post
please tell me if it works
BTW: the $XYpExe varibable was not necessary, I deleted it
Thanks again autocart. Well the error has gone and partial success:
I've copied and run the script exactly as your post (apart from changing Adresse).
1. run script
2. click whatever is supposed to open WE
3. WE opens and closes
4. XY doesn't open and nothing else happens

But only on the first click. Any subsequent click results in normal behaviour (WE opens and nothing else happens).

autocart
Posts: 903
Joined: 26 Sep 2013 15:22

Re: [AHK] redirecting win explorer windows to XYp

Post by autocart »

please, let me quote myself:
autocart wrote:I admit that the code is far less then perfect. For anyone using it would not hurt to understand a little bit of autohotkey.
you should be able and willing to experiment a little. For example XY needs to be running already. Also the script does not "move" all paths from WE to XY -> it is up to you to review/change the "filter" of what is being "moved" in the code on your own. also other behaviour of the script may not always be as wished in all details. so feel free to improve your ahk skills and to change the code to your liking. :)

kiwichick
Posts: 290
Joined: 08 Aug 2012 04:14

Re: [AHK] redirecting win explorer windows to XYp

Post by kiwichick »

Thanks autocart, I totally appreciate what you're saying. I don't understand most of what the script does so it's probably a bit beyond my abilities.

I did, however, manage to create a little script of my own that does it quite well (at the moment anyway). It opens in the current tab (which is XY default behaviour) but I'm hoping I can utilise your bit of code for the new tab.

Code: Select all

#SingleInstance force
#Persistent

xypath = C:\PortableApps\XYplorer\XYplorer.exe

While 1
{
winwait, ahk_class CabinetWClass
controlgettext, textvar, ToolbarWindow322
stringtrimleft, address, textvar, 9
winclose

run %xypath% "%address%"
}
Feel free to have a play with it yourself if you wish :-)


UPDATE: Actually didn't need any code for a new tab. Just used XY's "Open command line start path in new tab" in Configuration/Startup & Exit.

autocart
Posts: 903
Joined: 26 Sep 2013 15:22

Re: [AHK] redirecting win explorer windows to XY

Post by autocart »

Hi all,
ok, I "rewrote" my script, code above got updated.

I also made an exe for those who trust it (downloadable from the 1st post). Command line params: "paths/keywords" to be excluded from getting redirected (like "Computer" "Libraries" "Pictures" ... or real whole paths)

XY needs to be running/started manually though. Also I did not take care of multiple Explorer or XY scenarios.

Hint:
If in XY under Tools/Configuration/Other/Shell Integration I check "XYplorer is default file manager" then Firefox-Download-Open-Containing-Folder will also open XY but not mark/highlight the file. If I uncheck "XYplorer is default file manager" and use my tool instead then it will also mark/highlight the file.

@binocular222:
I used your idea now - thank you for that.
However, the way you posted it, it does not work.
as an extra 1st line it needs:
Gui +LastFound

Regards, Stephan
Last edited by autocart on 05 Apr 2020 00:15, edited 1 time in total.

binocular222
Posts: 1414
Joined: 04 Nov 2008 05:35
Location: Hanoi, Vietnam

Re: [AHK] redirecting win explorer windows to XYp

Post by binocular222 »

Shellhook method only works with new parent window (not work with child window)
I'm a casual coder using AHK language. All of my xys scripts:
http://www.xyplorer.com/xyfc/viewtopic. ... 243#p82488

Post Reply