LinkedTab_AutoOpen_Handler: Open related folder tabs automatically

Buttons/Scripts
, ,
24

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:.