LinkedTab_AutoOpen_Handler: Open related folder tabs automatically

Sorry abr! I had been busy with a new job since summer and hadn't been looking at the scripting forum.

I'm still real busy :slight_smile:... but have been doing some scripting for myself lately. So with that having recent bit of work having helped dust off the cobwebs from my scripting skills, and with the holidays approaching - I will take a run through the forum here to see what requests came my way that I never responded to :frowning:.

Hey abr!

So... fairly significant changes so PLEASE TEST BEFORE RELYING ON IT. I've renamed the entire script and package, so if you'd like - just DISABLE the old package by UN-checking it's main listing in Prefs rather than deleting the old package - at least while you test and prove out the new version.

Here's a (mostly) full rundown of the changes:

First: please note that as mentioned - I've renamed the package from OnAfterFolderChange_LinkedTab_AutoOpenClose to LinkedTab_AutoOpen_Handler. When some of my scripts started handling multiple events, it just didn't make any sense to prepend the script names with the event(s) it was handling.

In addition, I've pulled the OnCloseTab_LinkedTab_AutoClose component out of the package. It's otherwise always available as a separate package download...

Beside that, here's a list of new and changed options I implemented in v1.2.0 based on your previous request(s):

  • Always_On: allows use of the script without having to enable it via environment variables (replaces old LinkedTab_AutoOpen option, but is now entirely separate from env var based control)
  • DEBUG_CLEAR: renamed from old option CLEAR_OUTPUT
  • LinkedTabList: renamed from old option objLinkedTabList
  • Openindual_Mode: allows setting the preferred dual display mode (vertical or horizontal)
  • OpenLinkedTab_Action: allows setting a user defined Opus command to be run after the scripts normal function. For instance, if you disable opening the paired folder in SLAVE tabs (new option below), perhaps you want to enable NavLock instead - OR - NAVSYNC :slight_smile:.
  • OpenLinkedTab_Slaved: allows controlling whether or not the linked paired folder tabs are SLAVED or not
  • QualKey: renamed from old option LinkedTab_AutoOpen_QualKey
  • Qualkey_Disable: allows setting a qualifier key to DISABLE the scripts

In addition to the new and revised options, I've also implemented a LinkedTab_AutoOpen command in this version. The command functions as follows:

The LinkedTab_AutoOpen script command is used to:

  • RESET the current source tab to the initial path defined in scripts LinkedTabList option
  • RESYNC the current (or new) linked destination tab with the current source tab

Command Arguments:

Argument  Type  Possible values  Description

RESET     /S    (no value)       Compares the current source tab path to the list of all path entries
                                 in the scripts LinkedTabList option. If the script determines that the
                                 current path is a child of any of those defined as a paired folder in
                                 the option, then the source tab is reset back to that initial path.

RESYNC    /O    (no value)       With no optional value, the RESYNC argument defaults to the read behavior
                                 described below...

                create           Compares the current source tab path to the list of all path entires in
                                 the scripts LinkedTabList option. If the script determines that the
                                 current path is a child of any of those defined as a paired folder in
                                 the option, then the difference between the initial path saved in the
                                 option and the current path is set as a 'relative path'.

                                 The script then checks to see if this path exists relative to the
                                 'paired' folder path. If it [b]DOES[/b] exist, the current linked
                                 destination tab (if no dest tab is open AND linked, a new one will be
                                 opened) is then switched to that relative path, one sub-folder at a
                                 time (in order to provide a backlist history that might match the
                                 source). If the relative path does [b]NOT[/b] exist, the script will
                                 try to create it and then open it.

                read             Performs a similar 'relative path' as the 'create' option, however
                                 if the path does NOT exist relative to the 'paired' folder path, no
                                 attempt to create the missing folder structure in it is performed.

                                 Instead, the 'read' option functions similarly to the RESET argument,
                                 but for the destination tab instead of the source.

                                 Note that this doesn't truly 'sync' the two tabs... but it's a way to
                                 get the linked paired folder tab open to its initial path if for some
                                 reason one wasn't opened when you first entered the trigger folder in
                                 the source. This could happen if you rely on either the environment
                                 variable or hotkey script controls, and simply forgot to use one of
                                 those methods before navigating down into the source folder structure.

                                 It prevents you from having to go BACK, and then turn on the script
                                 controls, then navigate forward again - all just to get the paired
                                 folder tab open.

Root post updated again with sample toolbar button for the environment variable based script control...

Oh - and abr, if you have both paired folder tabs open, you can also use both the new command line options together in order to set BOTH tabs back to their defined initial paths:

LinkedTab_AutoOpen RESET RESYNC

In case you get all twisted around in diverging sub-folders and want to get back to square one. This combo command will also reset the source tab and open a NEW linked tab to the initial paired folder if you didn't already have it open. Here's a toolbar menu with all the different command line combos I tested - if you'd like to see what all the combo's do in different situations:

<?xml version="1.0"?>
<button backcol="none" display="both" label_pos="right" textcol="none" type="menu">
	<label>LinkedTab_AutoOpen</label>
	<icon1>#dualdisplay</icon1>
	<button backcol="none" display="both" label_pos="right" separate="yes" textcol="none">
		<label>Reset</label>
		<icon1>#dualdisplay</icon1>
		<function type="normal">
			<instruction>LinkedTab_AutoOpen RESET </instruction>
		</function>
	</button>
	<button backcol="none" display="both" label_pos="right" textcol="none">
		<label>Resync (default)</label>
		<icon1>#dualdisplay</icon1>
		<function type="normal">
			<instruction>LinkedTab_AutoOpen RESYNC</instruction>
		</function>
	</button>
	<button backcol="none" display="both" label_pos="right" textcol="none">
		<label>Resync (create)</label>
		<icon1>#dualdisplay</icon1>
		<function type="normal">
			<instruction>LinkedTab_AutoOpen RESYNC=create</instruction>
		</function>
	</button>
	<button backcol="none" display="both" label_pos="right" separate="yes" textcol="none">
		<label>Resync (read)</label>
		<icon1>#dualdisplay</icon1>
		<function type="normal">
			<instruction>LinkedTab_AutoOpen RESYNC=read</instruction>
		</function>
	</button>
	<button backcol="none" display="both" label_pos="right" textcol="none">
		<label>Reset + Resync (default)</label>
		<icon1>#dualdisplay</icon1>
		<function type="normal">
			<instruction>LinkedTab_AutoOpen RESET RESYNC</instruction>
		</function>
	</button>
	<button backcol="none" display="both" label_pos="right" textcol="none">
		<label>Reset + Resync (create)</label>
		<icon1>#dualdisplay</icon1>
		<function type="normal">
			<instruction>LinkedTab_AutoOpen RESET RESYNC=create</instruction>
		</function>
	</button>
	<button backcol="none" display="both" label_pos="right" textcol="none">
		<label>Reset + Resync (read)</label>
		<icon1>#dualdisplay</icon1>
		<function type="normal">
			<instruction>LinkedTab_AutoOpen RESET RESYNC=read</instruction>
		</function>
	</button>
</button>

Some of what I did in this release to answer a couple of requests you had here was adapted from my new NavSync script... which - based on your comments about, we might have some situationally similar feelings about:

Yeah, I like some of the SLAVE tab features - but that one is a head scratcher for me (personally). If you enabled slave tabs while in DIFFERENT locations to begin with, I just don't see why you would ever want to see the exact same location in both tabs just because you went "out-of-sync" by entering a folder in the source that doesn't exist in the destination.

To each their own :slight_smile:. Neither NavLock or Slave tabs work exactly to my liking - so NavSync was a goal I had in mind ever since the first v11 BETAs with scripting were released.

Whether you are interested in checking NavSync out or not, I implemented the OpenLinkedTab_Slaved option so you can set that to False to prevent slave tabs (linked but-non-slaved tabs are still required for the script to do a bunch of things though)... But NavSync (final plug) doesn't do anything (by default) if you go out-of-sync... so it will let you sync the navigation of both tabs, but not have unwanted side effects if you do happen to enter a folder that is not common to both tabs.

Final three comments for now:

  1. About per folder pairing options for handling things like SLAVE tabs or not, let me know if that's something you're really interested in, and I'll figure something out. May another separator at the end of the paths like double-colons or something (::slight_smile: since that can't be a valid path string...

  2. About @keydown tricks to override slave tab behavior, I don't think we have the ability to do that in the scripting interface...

  3. Be aware that I've switched from using Opus FSUtil.Resolve method to resolve paths like those for Libraries - to the FSUtil.DisplayName method. The impact of this is that it still serves the purpose which I used either of them for - but it has the benefit of now NOT transforming the virtual lib:// based paths into their physical [b][drive_letter]:[/b] based paths. Not sure how much you might have noticed anything like that happening before I added some of these new features... If you work with libraries much - you may only have even noticed something was strange there if you looked at the logs where you would have seen lib paths converted into drive letter paths...

Feedback appreciated... the script name changes mean you'll have to redo your configuration options (most of which changed anyway), but I didn't change the environment vars involved since I didn't want you to ALSO have to update toolbar buttons, hotkeys, and whatever else :slight_smile:.

Just tested it with DO12, but it doesn't work anymore.

Steje, thanks again for this very useful script! I was wrong, or must have changed something, but it is working again! :slight_smile:

:thumbsup:

Hi, just found this script, absolutely amazing :slight_smile:

I have a (hopefully) small feature request: Wildcards or RegExs. I have a bunch of folders (in the form *\bin\Release) that I always want to open another folder with.

But even if that doesn't work, really helpful as is, thank you for your work :slight_smile:

@abr: glad to hear! Yeah, from our email back and forth - I was looking for you to clean out all the older versions of the script (which used different script filenames) and just run the latest posted versions. Glad it's working in v12 - not all my scripts are :question:

Was there anything else you had asked me to do with this script (enhancements)?

@CWagner: I might have some time this week to look at your enhancement idea. I haven't revisited it in a while so I have to remember how it works - lol. Lucky for me my code comments are often more lengthy and verbose than my forum posts :thumbsup:

Thanks, steje. Yes, i think there was something, but i need re-check things, before i can say, what it exactly was. I think, one thing was, that i wanted a change regarding the automatic linking. Also, maybe a slightly different way to fetch the befriended folder. I will report back soon.

Okey! Yes, I remember you wanting a way to disable the auto-linking.

If you DON'T normally want the paired path tabs to be slaved together - I added the OpenLinkedTab_Slaved script config option last year which disables slaving the tabs when set to False. Is that good enough, or do you in fact want some sort of an ON DEMAND WAY to enable/disable the slaving of the tabs? Slaving tabs manually is really easy - just <Ctrl+click> one of the tabs.

I also added a script command to the last script package update (1.20) so that you have the ability to do what you asked for with THIS request from awhile back:

As well as what I think you might have meant from your last comment:

So for this I added the LinkedTab_AutoOpen script command that lets you call up the paired folder after the fact in the following sort of scenario:

  • LinkedTabList has a set of paired folder paths like: D:\folder1 || E:\folder1
  • You opened D:\folder1\folder2\folder3 BEFORE enabling the script to auto-open E:\folder1, and now you want E:\folder1 opened withOUT having to go back up to D:\folder1 and toggle the script on, then navigate back to the sub-dir you were in
  • Running the LinkedTab_AutoOpen RESYNC=read script command will then leave your source tab positioned in the current D:\folder1\folder2\folder3 path while opening the paired E:\folder1 folder path in the other display

So I ~think that covers most of what you had asked for. Check out my last big update from 12/29 last year with a big button with variations on the use of the script command to see what the options do and let me know.

Thanks again, steje. I'm looking forward to test the new code. I've only fast-read your answer, will have to plunge into it later. The bottom part sound very interesting. I will test it, & maybe it's aleeady better than what i have thought about, some kind of hotkey to open the friends folder in the destination side. By the way, i'm glad you have provided so many modifier keys, because my old "Win-Enter" combination did not work any longer. That's a typical problem, when you have so many different shortcuts for different applications, even though most of them are not global. Luckily, many programs allow you to white list things, so it would work only in that specified context.

I am confused a bit now. Which modules exactly do i have to use to get the functions, you´ve described? Also, im not sure i have actually downloaded the latest version. Here´s a picture of the modules in use.

You can certainly bind a standard Opus hotkey to run the LinkedTab_AutoOpen RESYNC=read script command...

By the way, with soooo many different things people want to use hotkeys for (you're not the only one - I recall some other users here on the forum talk about actually running out of hotkey bindings - that they can remember anyways), one thing you could consider doing is that for Opus scripts that use environment variables (like most of mine use) to enable/disable the script functions, you can also create hotkeys that do different things with the SAME qualifier keys - depending on what environment variables are set.

For instance, consider things like (as a hotkey):

@ifset:$lst:linkedtab_autoopen
LinkedTab_AutoOpen RESYNC=read

@ifset:$glob:SCRIPT_DEBUG
@confirm Script debugging is enabled...

@ifset:else
go newtab

So for such scripts - you can consider create context sensitive hotkey bindings based on Opus environment variables providing the context... yay! I've been thinking of writing a script wrapper to provide better conditional control over 'what to do' based on what vars are enabled, since the @ifset modifier in Opus doesn't really allow a scripts level of flow control. You could even get a bit advanced to catch conditions when you're using multiple script at the same time and you want a hotkey to do multiple things under multiple script based variable control, even a popup menu with a list of actions to take depending on what vars are enabled, where you can enable a checkbox, hit ok - then the script performs a series of actions based on you having pressed the hotkey.

Let me know if you're interested in such a thing... I have a few tweaks to my old scripts to take care of - then will probably work on such a hotkey wrapper script.

This update adds support for Ctrl and Alt qualifier keys... which I guess I left out originally when it was bundled with the LinkedTab_AutoClose script, since those qual keys are hard coded in Opus to do other things when dbl-clicking on tab headers.

I've also added some experimental support for the use of regular expressions in response to CWagner's request. This is currently only supported for use in the uni-directional format for the LinkedTabList property. This so that when entering a folder whose path matches the regex, an absolute path can then be referred to to open the paired folder. Regular expressions should be placed as the first part of a uni-directional paired folder entry using && as the delimiter, and should be pre-pended by the string re://:


As shown above, the very simple regex of temp will cause the script to open a linked tab for [b]d:[/b] any time a folder named temp. The script creates a standard VBscript regex object then sets the pattern to the value following the re:// prefix... You should take any case sensitivity concerns into account in the regex itself.

@abr: I've just posted a new version - so please grab v1.2.2 from the root post.

In addition, you should get rid of the older 1.0.8 version all-together. The one named: OnAfterFolderChange_LinkedTab_AutoOpen

Steje, thanks. However, i am completely lost now. I have to admit, that i have no idea how to set up the whole command. My last try ended up in some infinite loop. I have to begin from scratch. If i understand right, all i need to use is the Linked_Tab_AutoOpenHandler, but not Linked_Tab_AutoCloseHandler?

I have tried "LinkedTab_AutoOpen RESYNC=read" (also, without the "read"), which led to smoe infinite loop, opening lots of identical messages at the bottom of the lister. With the other command

<?xml version="1.0"?>
<button backcol="none" display="both" label_pos="right" textcol="none">
   <label>LinkedTab_AutoClose</label>
   <icon1>#closetab</icon1>
   <function type="normal">
      <instruction>@toggle:if $lst:linkedtab_autoclose</instruction>
      <instruction />
      <instruction>@ifset:$lst:linkedtab_autoclose</instruction>
      <instruction>@set lst:linkedtab_autoclose</instruction>
      <instruction />
      <instruction>@ifset:else</instruction>
      <instruction>@set lst:linkedtab_autoclose=true</instruction>
   </function>
</button>

absolutely nothing happened, because i obviosuly didn't understand, waht i am doing :smiley:, while with the other code (i can't even find that in the two threads right now :blush:) i get some empty lister side. I slao don't know, if there is some new, completely insdependent command, or do i still need to push the qualifier key plus Enter? I have to look into it in the afternoon, maybe i find something new.

(i meant this code

@toggle:if $lst:linkedtab_autoclose

@ifset:$lst:linkedtab_autoclose
@set lst:linkedtab_autoclose

@ifset:else
@set lst:linkedtab_autoclose=true

it does nothing at the moment, as it surely doesn't make much sense, what i've tried so far). Maybe you can help me to start from scratch? Here are my basic questions

  • Which module do i need (only LinkedTab_AutoOpenHandler v.1.2.2, i suppose) (i have thrown out that 1.08 module, like you have suggested)

  • do i need qualifier keys at all, or is there some other single command to open the other folder from within one folder (which is how i understood)

I also have to find out about the new re:// part, which looks quite interesting. Thanks, i will keep trying, & looking forward to get it to work!

You'd do well to read the threads :slight_smile:...

I originally bundled this script with a second/companion script that handled the 'auto close' of a linked tab - but later broke it out to it's own script. So for THIS 'auto open' script, the variable names you mentioned above do nothing (they are the variables to control the 'auto close' script). Check the root post of this thread for the 'linkedtab_autoopen' vars needed to control this script.

For the other problems, all I can suggest is to go into the script configuration options in Prefs, and enable the DEBUG option (set to True). Grab a screenshot of the scripts config options as well as the entries in the LinkedTabList option and post them here along with the log (you can copy the script log from the Opus' Output Window).

I will do that. Thanks steje. It's a big thread, with many changes, but i will work through it again. :slight_smile:

Just look at the updated root post as well as the Dec 29 2015 entry here... That should be all you need to look at.