LinkedTab_AutoOpen_Handler: Open related folder tabs automatically

[steje]

Note: This script now requires a minimum Opus version 11.16...

This script was written in response to a request from abr in the following discussion:

DO11: scripting, triggering new tab by opening folder?

What does it do?:
The purpose of this script is to provide a way for users to associate two folder paths with one another such that entering 'one' will cause Opus to automatically open the 'other' in a new tab in the opposite file display (switching to dual file display if currently in single display mode). The two folder tabs are also then linked as slave tabs. The method by which the trigger folder is opened does not matter... the script will respond whether one of the trigger folders is opened via double-click, key, some other use of the 'Go' command, or clicking on it in the folder tree. All of these methods of opening a folder generate the OnAfterFolderChange event which the script responds to. The script also checks for existing linktab state in order to avoid opening duplicate tabs if you go back/forward through one of the trigger folders.

How to install and use it?:
The script is provided here as an Opus Script Package... which in turn is actually a zip file with a VBScript packaged inside. It can be installed by either manually copying the OSP file to the /dopusdata\Script AddIns folder, or via drag-and-drop into the Preferences / Toolbars / Scripts page.

Download: LinkedTab_AutoOpen_Handler.osp (5.71 KB)
Notes:
2014-03-19: Initial release...
2014-03-25: v1.0.5 - Script updated, adds multiple options and now requires a minimum Opus version of 11.1 Beta 3
2014-03-26: v1.0.8 - Script updated, no ~functional changes, just settled on a consistent method of enabling debug via a global SCRIPT_DEBUG variable
2015-12-29: v1.2.0 - Script renamed to match my new standard, added support for multiple new options, and minimum required Opus version is now set to 11.16
2016-11-22: v1.2.2 - Minor update to include support for Ctrl and Alt qualifier keys. Also added some test support for use of Regex in setting the paired folder association. This is currently only supported in uni-directional mode. More info here

As of the v1.2.0 update, I've separated the OnCloseTab_LinkedTab_AutoClose.vbs script component out of this package. They're not directly related, and I've long since uploaded the LinkedTab_AutoClose_Handler: Auto-close linked tabs as its own standalone script... so grab BOTH if you want to use these features together.

After installing the script package, users must define the full folder paths for the folders they want associated for the purposes of this script. This can be done via the scripts Configuration dialog.

The Configuration dialog will display a LinkedTabList property for the user to make one or more entries:

The script allows for both unidirectional and bidirectional relationships...

Examples of each type of relationship:

Unidirectional - using && to separate the two folder paths:
Opening the FIRST folder will cause the SECOND folder to be opened in a new tab, but not the other way around:

C:\Temp && D:\Temp

Bidirectional - using || to separate the two folder paths:
Opening EITHER of the folders will cause the OTHER folder to be opened in a new tab:

lib://My/My Media/My Music/~new || D:\Music

In addition to the qualifier keys that can be set to enable/disable the scripts execution (qualifier keys require the Always_On option to be set to True), script execution can also be enabled by the use of an Opus environment variable called linkedtab_autoopen.

Here is a sample toolbar button that toggles the lister scoped variable (the script supports tab, lister or global scoped variables) which you can copy and paste directly to your toolbar:

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

...feedback appreciated!

[Leo]

Nice one! Glad to see you got to the end of this journey. It sounded like a complicated script, especially to write right now when it's all new to everyone. Paving the way.

[steje]

Thanks for the ack! Wasn't terribly complicated in the end... was more work to muscle through some of the earlier bugs and limitations than the actual working code that gets the job done.

Thanks to you and Jon for being so supportive! Particularly during my several flurries of heavy post, retest, repost, retest again antics being played out in the forum threads .

I've got some ideas for my own scripts now - now that I've used a few other people as guinea pigs for getting my feet wet with Opus scripting -

[tbone]

This is neat!.. o)

The AutoClose does not close the automatically opened dest-tab, if the trigger/source tab has been closed, does this work as designed?
The other way round it works (closing the automatically opened tab, closes the trigger/source tab).

I like to thank you for being one of the early birds, pushing hard on the scripting front!.. o) I hope to find some time to dive into this as well, tempting terrain.. o)

[steje]

What exact version/build of Opus are you running...?

What you asked works fine here (I tested it a bit before I released it for this very thing).

[abr]

I have tested this script now for a couple of days, & it works very good. There are a few things, though, which a almost have expected, when i suggested this function:
First, it would be good, if there was a way to toggle the script on & off (which applies for all scripts in general, i would say) in a quicker way (not having to do it in the prefs).
When i first used it, i found the script interferring with my default tab sets, which had some of the paths open, that would trigger the script immediatley.

This is the natural behavior, off course, because that's exactly what the script is supposed to do. It was easy to change the #styletabs.xyz used in the various styles to some
fixed tab groups, which are loaded now, so that the (sometimes) unwanted interferring is under control now.

So, my two suggestions for now would be, to have a function, to toggle scripts one/off (which isn't in Steje's scope, i guess, but more in Jon's), & maybe the ability to bind some extra key
to the triggering function, so we could decide if the partner folder is to be opened or not based on the use case. For that reason it would be interesting to know, if it's possible to use
a (different) shortcut to open locations, telling the command to use the script or not (or, if folders are clicked directly, to have some modifier key like "Alt" defined, which would use the script,
or behave normal, if the modifier key isn't pressed). It would also be interesting, to think about expand the function, so that opening one specific folder could also open more then one
corresponding tab. I use the tab groups function a lot, especially since it was improved. But this would mean some useful extension to the tab groups, since often i just want to open a few
extra tabs, instead of a whole new tab group.

[steje]

@abr

So, my two suggestions for now would be, to have a function, to toggle scripts one/off (which isn't in Steje's scope, i guess, but more in Jon's), & maybe the ability to bind some extra key
to the triggering function, so we could decide if the partner folder is to be opened or not based on the use case. For that reason it would be interesting to know, if it's possible to use
a (different) shortcut to open locations, telling the command to use the script or not (or, if folders are clicked directly, to have some modifier key like "Alt" defined, which would use the script,
or behave normal, if the modifier key isn't pressed). It would also be interesting, to think about expand the function, so that opening one specific folder could also open more then one
corresponding tab. I use the tab groups function a lot, especially since it was improved. But this would mean some useful extension to the tab groups, since often i just want to open a few
extra tabs, instead of a whole new tab group.

A few comments...

Toggling scripts on/off actually IS entirely in scope . It just requires scripts to be written in such a way that allows it. As was done in a previous script I posted, we can use the new global/lister/tab environment variables to control things like script behavior. Whether or not GPSoft intended for the vars to be used this way with scripts or not - it works great, can be toggled by any standard means in Opus (button/hotkey) and is easy to add... how do you want it to work? On by default, or off by default?

About using qualifier keys... in this case, it can be done... but would need for the script to be re-written as a ScriptCommand instead of as an 'event handler' so that using (f.ex.) Left double-click + Alt on the All Folders filetype would then be able to be configured to run the ScriptCommand. However, this would only cover dbl-clicking on folders, and not catch other methods of opening the trigger folders. If we are ever able to get access to qualifier keys held down during whatever actions fire the Events we can register in the scripting interface (this one uses OnAfterFolderChange), then we can still do everything in the event handling script approach this script uses... I've asked for exactly this while writing this script and realizing it would be very useful for this and several other ideas I've had, but have no idea if we'll ever see it happen. It would ALSO be useful for the piece of this script that auto-CLOSES the linked tab... based on the OnCloseTab event, at which point that piece could be broken out of this script and made generally useful for people as an on-demand way of using a qualifier key to auto-close linked tabs in any arbitrary use-case not related to the intent you had with this particular script.

Cool stuff - sooooo grateful to GPSoft for these interfaces in v11.........

[abr]

@steje

A few comments...

Toggling scripts on/off actually IS entirely in scope .

It just requires scripts to be written in such a way that allows it. As was done in a previous script I posted, we can use the new global/lister/tab environment variables to control things like script behavior. Whether or not GPSoft intended for the vars to be used this way with scripts or not - it works great, can be toggled by any standard means in Opus (button/hotkey) and is easy to add... how do you want it to work? On by default, or off by default?

I would say, rather off by default, because mostly i want to just browse various locations with no copying or comparing intended. Most of my "connected" folders are on hard disk / USB drive combinations, so i would only use the script, whenever i want to copy items to the USB drive, or compare stuff (or sometimes the other way round).

About using qualifier keys... in this case, it can be done... but would need for the script to be re-written as a ScriptCommand instead of as an 'event handler' so that using (f.ex.) Left double-click + Alt on the All Folders filetype would then be able to be configured to run the ScriptCommand. However, this would only cover dbl-clicking on folders, and not catch other methods of opening the trigger folders.

Well, that's surely in need of improvement. Aside from the task here (the script i asked for), it would be very handy in a lot of situations. Like, people wanting to trigger various scripts on folders, which calls for modifier keys. For example, clicking a folder with no modifier just opens it, plus holding Alt -> triggers script A on that folder, or holding Ctrl -> uses script B, etc.

As for the problem with the double click, yes, that's a bit of a problem, & i was already thinking about that. Because i normally don't click much in Opus, but navigate either using the keyboard ("ENTER" to enter a folder), or jump to a folder using the alias system (would be keyboard, too), which perhaps isn't ready at all to work with modifier keys (actually Opus would have to be aware of the mod key being held down, when i enter the alias name).

But it would be about 95-98% ok for me, if it only worked with entering a folder directly, using the "Enter" key - or going to that location via shortcut (for example, the multi key Alt-L-O would open a special location, which is in the script's list, so the associated folder would be opened by the script), so the alias approach is maybe negligible. On the other hand, i don't know, how the aliases actually work. Maybe they are converted into common "go" commands at some early stage, so that the script could "hook" into the process in almost the same way, as if a common "Go" was used in a shortcut? Like i said, it's not important, but there are only 4 ways to open folders anyway (as far as i'm aware of): double clicking a folder, using enter, using a shortcut, or using the alias. So it wouldn't hurt, if all cases could be covered.

If we are ever able to get access to qualifier keys held down during whatever actions fire the Events we can register in the scripting interface (this one uses OnAfterFolderChange), then we can still do everything in the event handling script approach this script uses... I've asked for exactly this while writing this script and realizing it would be very useful for this and several other ideas I've had, but have no idea if we'll ever see it happen.

I hope so. Because that would be consistent with the modifier key approach we have for the other commands (which i use a lot, btw.).

It would ALSO be useful for the piece of this script that auto-CLOSES the linked tab... based on the OnCloseTab event, at which point that piece could be broken out of this script and made generally useful for people as an on-demand way of using a qualifier key to auto-close linked tabs in any arbitrary use-case not related to the intent you had with this particular script. Cool stuff - sooooo grateful to GPSoft for these interfaces in v11.........

True. Bits of the script's "modding" abilities could be very modular, i think. But at the same time, they (the scripts) might also be like deep, unexplored waters. Lots of debugging awaiting, even complicated by the fact, that there's not only one, but several script languages available, each one capable of causing the most beautiful, weird side-effects yet to be explored But it is worth it, i'm sure.

[steje]

Ok, I've updated the script... quite a few changes, so please test:

Added new options to the OnAfterFolderChange_LinkedTab_AutoOpen script:

• The LinkedTab_AutoOpen option (set to True by default): enables and disables the script from performing it's function. The reason I added it as a Script Config option rather than leave that up to only deselecting the scripts checkbox in Prefs is so you can enable the script "on-demand" by toggling an environment variable called linkedtab_autoopen. The script supports setting that variable name as either a Global, Lister, or source Tab scoped variable. Here's an example global toggle toolbar button:

@toggle:if $glob:linkedtab_autoopen

@ifset:$glob:linkedtab_autoopen
@set glob:linkedtab_autoopen

@ifset:else
@set glob:linkedtab_autoopen=true

• The LinkedTab_AutoOpen_QualKey option (set to none by default): lets you set the qualifier key you want to trigger the script. The script supports any of the keys supported by the script interface (shift, ctrl, alt, lwin, rwin) and when set at the default of none then the script will fire whether a qualifier key is held down or not...

@abr

But it would be about 95-98% ok for me, if it only worked with entering a folder directly, using the "Enter" key - or going to that location via shortcut (for example, the multi key Alt-L-O would open a special location, which is in the script's list, so the associated folder would be opened by the script), so the alias approach is maybe negligible. On the other hand, i don't know, how the aliases actually work. Maybe they are converted into common "go" commands at some early stage, so that the script could "hook" into the process in almost the same way, as if a common "Go" was used in a shortcut? Like i said, it's not important, but there are only 4 ways to open folders anyway (as far as i'm aware of): double clicking a folder, using enter, using a shortcut, or using the alias. So it wouldn't hurt, if all cases could be covered.

...it works however you get to a folder that causes Opus to fire the OnAfterFolderChange event... which includes using a folder alias .

Similar options were added to the OnCloseTab_LinkedTab_AutoClose script:

• If you disable this script using it's LinkedTab_AutoClose option... then you can similarly control it's behavior using the sort of toggle button above. Just replace the variable name with linkedtab_autoclose.

• Note that the LinkedTab_AutoClose_QualKey option only supports using shift, lwin, and rwin keys due to alt and ctrl already being hardcoded for use by Opus...

From a script writers perspective:
While each member script of this script package can still have debug enabled at the individual script level... when working on scripts I've borrowed an idea from you and wowbagger to use an environment variable called SCRIPT_DEBUG to enable debug messaging for all my scripts in one go from a toggle button on my scripting toolbar. Very convenient...

[steje]

By the way... thank GPSoft for rocking out support for qualifier key properties for Opus generated Events. That was just released 2 days ago in v11.1 Beta 3, awesome!

Note: v11.1 Beta 3 is now minimum required version for the script to work...

[wowbagger]

@steje

use an environment variable called SCRIPT_DEBUG to enable debug messaging for all my scripts in one go from a toggle button on my scripting toolbar. Very convenient...

Should we standardize on a single global variable? It makes sense to me, I would like my button to enable debug in your scripts. I'm happy to use $glob:SCRIPT_DEBUG, I was using $glob:debug.

[abr]

Great news, thanks steje & GP (for the quick reaction in Beta 3), i'm looking forward to test the script this evening!

[steje]

@wowbagger

Should we standardize on a single global variable? It makes sense to me, I would like my button to enable debug in your scripts. I'm happy to use $glob:SCRIPT_DEBUG, I was using $glob:debug.

Not opposed to standardizing... but I'm going to keep my current SCRIPT_DEBUG flag for now since I'm using a regular 'debug' variable for other things that are not specific to scripting.

[steje]

I just updated the package again - I've moved the SCRIPT_DEBUG variable I was using up a level and made it a global script variable so that I don't actually have to pass it as an arg to my log handling Sub... If I write a script that handles more than one event, then I'll just check for the env var ONCE in each event handler function.

@wowbagger: though it doesn't seem to matter all that much... I'd suggest you consider doing the same (regardless of what var name you want to use) so that you're not creating a new command object and looking up the env var state EVERY time you log a message. The value won't change in between logging of messages... really only in between execution of the event handling function.

[wowbagger]

@steje

@wowbagger: though it doesn't seem to matter all that much... I'd suggest you consider doing the same (regardless of what var name you want to use) so that you're not creating a new command object and looking up the env var state EVERY time you log a message. The value won't change in between logging of messages... really only in between execution of the event handling function.

Good idea, I will look at that. It does depend on the script though. If a script is performing some time consuming actions over many files it might be worth handy to be able to alter the debug status during the running (I do this for some of my scripts). That does not mean we need to create a new command every time we check the the value of the variable though, a global (to the script) command can be created.

[abr]

It works all as intended.

[abr]

I have to requests/ideas for this script:

Would it be possible, to have an option in the configuration to open the paired folders in non-linked or slave mode?
Another enhancement would be, if i could call the associated folder from within the other folder, which would sometimes save the step having to go up, & then use the
shortcut to re-enter the folder, to open the pair.

[steje]

Hey Andreas, I'll have a look this weekend. I think both of those things can be achieved... just not sure about the best way to alter the behavior. Meaning...

For the linking/slaving of tabs... I thought that was one of your fundamental asks with this idea. Now that you've been using it a bit... is the paired folder tabs being linked something you still think you'll want to do some times but not others depending on the particular work (or folder pairs) you're doing? I ask because a script config option is easy enough to add to control it, but would something that you could control more "on-demand" be preferable? Perhaps using some @keydown stuff in a button being used to toggle the script behavior "on" via another environment variable... or something similar based on the use of another qualifier key - if your using the QualKey option to control the behavior...?

For the opening the paired folder tab while already INSIDE one of the trigger folders... I have to think some more on what trigger mechanism might make sense to be able to do what you want there. I'm thinking for that, you'll also want to use a button driven environment variable that I can then key off of in order to evaluate the current path, see if any of the user specified folder paths are part of the current path string, work out the sub-folder between the two strings, and then see if that same relative sub-folder path exists under the paired folder path in the script options...

I'll think some more on it...

[abr]

@steje

Hey Andreas, I'll have a look this weekend. I think both of those things can be achieved... just not sure about the best way to alter the behavior. Meaning...

Ah, cool.

For the linking/slaving of tabs... I thought that was one of your fundamental asks with this idea. Now that you've been using it a bit... is the paired folder tabs being linked something you still think you'll want to do some times but not others depending on the particular work (or folder pairs) you're doing?

Well, the basic problem with the linked state occurs, when a paired tab pair opened, but i only want to change folders in one of them. For example, i have some folder on my USB drive, containing some new music. That folder has a "pair" folder, which is the root level of my music collection. So when i want to open one of its subfolders (those with the various genres), the linked tab would also change, but isn't supposed to do so, because it is intended to be the source location. Like it is now, actually both sides will show the same location after a folder has been entered. But to answer your question, yes, it would be quite handy, if every tab pair could have individual settings, depending on the use case.

I ask because a script config option is easy enough to add to control it, but would something that you could control more "on-demand" be preferable? Perhaps using some @keydown stuff in a button being used to toggle the script behavior "on" via another environment variable... or something similar based on the use of another qualifier key - if your using the QualKey option to control the behavior...?

It would be a good option, if there was a helper key in @keydown style, which would prevent the one side from reaction to some folders being opened in the other side, overriding the slaved tabbed behavior, so to say.
When i suggested the linked state, i was rather thinking about the closing of both tabs, after usage, than being apple to navigate both sides in a navlock style. So, for example, holding the shift key down, while entering a folder on one side would override the navigation sync.

By the way, the new function using the qualifier key works great, but i have to use Win or Alt in their variations (LWin, RWin, etc.), because both, Shift-Enter, as well as Ctrl-Enter seem to be hard coded into Opus' own functionality, so they work only for mouse usage. Shift-Enter opens the GO field, while Ctrl-Enter opens the properties box.

For the opening the paired folder tab while already INSIDE one of the trigger folders... I have to think some more on what trigger mechanism might make sense to be able to do what you want there. I'm thinking for that, you'll also want to use a button driven environment variable that I can then key off of in order to evaluate the current path, see if any of the user specified folder paths are part of the current path string, work out the sub-folder between the two strings, and then see if that same relative sub-folder path exists under the paired folder path in the script options...

I'll think some more on it...

Yeah, thanks. It is a bit lazyness, i admit, since i can always go up & then call the other folder.

[abr]

Hi steje

I just found this thread, & i'm looking forward to try it out (being a bit busy right now). Your old script is still in heavy use here, as a lightweight alternative to the tab groups, which i also use for other cases. For example, i have the folder in my GPS device connected to the corresponding location, where i keep all the GPX files. Cool!