XYplorer Beta Club
INTROHow the Script Generally Works
DOWNLOADSRegarding the Available Downloads Below
Newest Version for Download
Older Versions
INSTALLATIONNormal Installation
Optional: Compiling an EXE Version of the Script
CREDITS / 
CHANGE LOG
HOW TO CONTROL REDIRECTIONSAutomatic Control of Redirection
Manual Redirection
Manual Escape of Redirection
MORE SETTINGSAutomatic 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
KNOWN LIMITATIONS
IDEAS FOR THE FUTURE INTROHi 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:
- XY's setting "XY is default file manager" does not get respected by all 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 are still WE windows that get opened instead of XY windows or tabs (e.g. from within certain 3rd-party-software or for other reasons).
- 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 items that 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
The script consists of a main file, a config file, and, optionally, an icon file. All three files should be located in the same folder.
Running the main file starts the script. It stays in the system tray until manually exited through the script's tray context menu.
The config file contains the script's settings, including rules that specify which WE windows are redirected to XY - and which are left untouched. The settings in the config file can be customized by the user. There is a detailed explanation of the settings after the change log section and also inside the config file itself.
The icon file, if present, is used as a system tray icon. Otherwise, a generic AutoHotkey icon is used.
While the script is running in the system tray, it recognizes any WE windows when they first appear. If a new WE window should be redirected, the script reads the location and selected items shown in that WE window, closes the 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*.
DOWNLOADSRegarding the Available Downloads Below
I am purposely *not* offering a compiled exe version of the script but only the AutoHotkey source code. But trust me, installation is really easy (see below).
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 install AutoHotkey and run my script as such as described below.
And if you really want a compiled exe version of the script, it is also easy to do it yourself, as descibed below as well.
The download includes the following files:
- The script's main file:
The script's main file is named "redirectWEwindowsToXY_v#.#.#_[date].ahk", with "#.#.#_[date]" standing for the script's version number and release date, e.g. "4.2.1_210831". - The config file:
The config file is named "redirectWEwindowsToXY_v#.#.config.ahk", with "#.#" standing for the config file's version number, e.g. “4.2“. - The icon file
- A URL file pointing to the main AutoHotkey download page
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
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Change log below.
Older Versions
INSTALLATIONNormal Installation
- Download the zip file of the "redirectWEwindowsToXY" script (see "DOWNLOADS" above) and unzip it to any folder of your choice. If you want to, you can rename the script's main file "redirectWEwindowsToXY_v#.#.#_[date].ahk" (compare "Regarding the Available Downloads Below" above) to any name you want. But do not rename the config file.
(If you are updating to a newer version of the script and the config file's version number did not change, then you only need to update the script's main file.) - Download and install AutoHotkey v1 from https://www.autohotkey.com/download in one of the following two ways:
- Recommended: It can be installed the traditional way by downloading and running the normal "Setup" version ("ahk-installer.exe"). By default, ahk files are set to "run" when double clicking on them. During the installation process, ensure that this setting in the installation dialog is NOT set to "edit" by accident.
- AutoHotkey can also be used as a portable version. If you prefer that, download the "ZIP" version. Just unzip it and create a Windows shortcut to any of the included "AutoHotkey....exe" files. Open the shortcut's properties dialog. Inside the shortcut's properties dialog, add the path to the script's main file (see step 1) as command line parameter to the "Autohotkey....exe" path.
- Optional: Edit the redirectWEwindowsToXY_v#.#.config.ahk according to the settings described below (or described inside the config file).
- Run the script in one of the following two ways:
- If you chose the "Setup" version of AutoHotkey in step 2: Just run the script's main file, just as you would run an exe file.
- If you chose the "ZIP" version in step 2 (with creating a shortcut): Just run the shortcut.
Optional: Compiling an EXE Version of the Script
If you want a compiled EXE version of the script, it is really simple to compile it yourself:
- Download and install the AutoHotkey "Setup" version (see above).
- Then right-click on the script's main file (the config file must exist in the same location) and choose "Compile script" from the context menu.
If you also want to include the icon as file icon for the exe file, then instead choose "Compile with options..." or "Compile script (GUI)..." from the context menu. The compile dialog, that now appears, gives you the option to also use a file icon. (If no such option is present in the context menu, then, instead of right-clicking on the script's main file, go to the start menu, choose the AutoHotkey folder if present, and start the little helper tool "Convert .ahk to .exe" or "Ahk2Exe", whichever is present. In that case you will also have to manually fill out the script's file path and the desired destination folder for the compiled exe.)
CREDITSFirst 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
CHANGE LOGCode: 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 that 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 that 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, that 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 that 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 that 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 that 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 that 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 that 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 (that 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.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.
Passing 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).
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"
Choosing the Compare MethodHint:
In the config file there are some suggestions for keywords to be used on an English, German, and Spanish version of Windows.
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.
Specifying Exceptions from General RegEx PatternsHint:
Regarding RegEx, here are some helpful sites for learning and formulating:
https://www.regular-expressions.info/quickstart.html
https://regex101.com/ (a testing environment)
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).
Choosig What to Do with a Match - 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.
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.
Manual Escape of RedirectionHint:
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.
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 that 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.
MORE SETTINGSAutomatic 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
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.
Option to Close XY TabHint:
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.
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
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
Hint:
This feature can especially be beneficial with the setting to use a separate ini file in such a case (see below).
Separate Ini File for XY Read-Only InstancesRemark:
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.
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
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.
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 that add tabs to WE.
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 that I want to open in XY, it will be done automatically. The cons are that if I browse to a path that 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!
