Note: I rather imagine this script will work with earlier releases - but as most of the finishing work on it was done on Opus Beta builds 184.108.40.206 and 220.127.116.11, and some sanity testing on the most recent stable release 18.104.22.168 - I went ahead and made the minimum release 22.214.171.124.
This script was written for ME, and indirectly - maybe a little bit for Jon and Leo, since I’ve been a bit of a prick to them over the past few years since the old NavLock behavior from v9 was changed… So now they don’t need to hear me whine about it anymore . I had actually intended to finish this script LONG before now - I started this during the original v11 BETA’s when scripting was first implemented, but hit a bunch of limitations at the time and put it to the side. But GPSoft have made so many awesome improvements to the scripting interface since then - it’s time to finish the damn thing! Also, with having recently started working with multiple Opus configs for different environments, as well as using multiple monitors much more frequently than I used to - the fruits of the labor are enough to get me to work on it!
So ENOUGH preamble… however, just know that THERE ARE SOME ISSUES WITH THE SCRIPT… see next post for details!
What does it do?:
The purpose of this script is to provide an alternative to the built-in NavLock feature in Opus. The differences between this script and NavLock are as follows:
Loss of sync notification:
- NavLock throws up a slide-down notification at the top of the file displays with useful options for handling loss-of-sync situations, but I find that method far too disruptive to my use of the file display. Like… REALLY!
- NavSync instead provides several user-configurable options that allow control over how the script notifies you of a loss-of-sync condition. The Script Configuration option that controls this is SYNC_LOSS_PROFILE, and it allows the following selections:
[ul][li]NONE: No action is taken when loss-of-sync occurs.[/li]
[li]CUSTOM: When set, the script will look for the Opus Command values set by the user in each of the SYNC_LOST_ACTION and SYNC_REC_ACTION script config options.[/li]
[li]FORMAT: The script will change the folder format of the linked tab(s) that lost sync to a user-defined favorite format that must be called ‘navsync’. The user must first create this format themselves for this option to work.[/li]
[li]RESYNC: The script will attempt to automatically create the missing folder path(s) to automatically recover (really, prevent) loss of sync… If the attempt fails, no obvious action is taken other than any errors that might be thrown by the failed attempt to create the folder.
NOTE: This behavior can also be triggered on-demand by the NavSync RESYNC command.[/li][/ul]
Multiple Lister support:
- NavLock only works with two FILE DISPLAYS in the same lister.
NavSync works with tabs across multiple LISTERS in order to make NavLock-like functionality available to users who want to sync navigation across listers. This is an obvious nice-to-have for those of us that work with multiple monitors.
Switching between tabs:
- NavLock establishes a link between the current paths in each file display. In cases where you might have more than just TWO sets of similar folder structures, switching to one of them in another tab once you’ve navigated down the folder tree in the initial TWO synced tabs makes it cumbersome to true up the THIRD tab with either of the other two without seeing alot of the crazy out of sync notifications described above, as well as some cases where you end up with the exact same paths in both tabs, which I don’t think I ever want to have happen …
NavSync allows the user to switch tabs similarly to how linked slave tabs work where the synchronized navigation takes place explicitly between the linked tabs as opposed to whatever the current source and destination tabs are (which could be different than the tabs that are actually linked).
FUTURE == Optionally handle different tab situations in either of the following ways:
[ul][li]Automatically attempt to position the newly activated folder tab to the same relative position as the folder tab which was just left (the one that was just deactivated, in the same file display). If the path is not valid, optionally prompt user to perform the ‘resync’ function in order to create the missing folder path(s) in the newly activated tab.
[li]Automatically ‘reset’ the tab in the other file display back to the initial folder path it was in when NavSync was turned on. This is to provide an easy way of enabling NavSync between one of the originally synced tabs and the newly activated one - assuming the new tab has been opened to a common enough starting point with a similar folder structure as the other tab in the original synced pair of tabs…[/li][/ul]
Multiple (more than 2) tab support:
- NavLock only works with TWO tabs (again, in the same lister).
NavSync WILL support link and sync of up to FOUR tabs, open across up to FOUR listers by creating a vector of linked tab ID’s in the navsync environment variable of each tab. A more common use case than FOUR separate listers is probably two dual-display listers…
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.
NavSync.osp (8.09 KB)
2015-12-18: v1.0.9 (vb) - Initial release…
2015-12-23: v1.1.1 (vb) - Update release: Re-implemented as a BeforeFolderChange event handler.
2016-01-01: v1.2.1 (vb) - Update release: Had some failures in some Library path situations, so started using FSUtil.DisplayName to strip out the “?” based member folder notations from the path strings before comparisons, checks and log messages.
In addition to the script package, here is a sample Toolbar Button that calls the Script Command implemented by the script to control NavSyncs’ features. You can copy and paste the code below directly to your toolbar… It’s a three-button button, where the LMB toggles Navsync ON and OFF, and the RMB opens a menu with buttons for the TOGGLE, RESET, RESYNC and STATS commands. Details on these commands are provided below…
<?xml version="1.0"?> <button backcol="none" display="icon" label_pos="right" separate="yes" textcol="none" type="three_button"> <label>NavSync</label> <icon1>#navlock</icon1> <button backcol="none" display="both" label_pos="right" textcol="none"> <label>NavSync</label> <icon1>#navlock</icon1> <function type="normal"> <instruction>@toggle:if $src:navsync</instruction> <instruction /> <instruction>@ifset:$src:navsync</instruction> <instruction>NavSync OFF</instruction> <instruction /> <instruction>@ifset:else</instruction> <instruction>NavSync ON</instruction> </function> </button> <button backcol="none" display="both" label_pos="right" textcol="none" type="menu"> <label>NavSync Tools</label> <icon1>#navlock</icon1> <button backcol="none" display="both" label_pos="right" textcol="none"> <label>NavSync TOGGLE</label> <icon1>#navlock</icon1> <function type="normal"> <instruction>NavSync TOGGLE</instruction> </function> </button> <button backcol="none" display="both" label_pos="right" textcol="none"> <label>NavSync RESET</label> <icon1>#navlock</icon1> <function type="normal"> <instruction>NavSync RESET</instruction> </function> </button> <button backcol="none" display="both" label_pos="right" textcol="none"> <label>NavSync RESYNC</label> <icon1>#navlock</icon1> <function type="normal"> <instruction>NavSync RESYNC</instruction> </function> </button> <button backcol="none" display="both" label_pos="right" textcol="none"> <label>NavSync STATS</label> <icon1>#navlock</icon1> <function type="normal"> <instruction>Set UTILITY=OtherLog</instruction> <instruction>NavSync STATS</instruction> </function> </button> </button> </button>
After installing the script package, users can modify the options described above to control things like the logging level, and what type of actions to take when a loss-of-sync condition occurs… This can be done via the scripts Configuration dialog.
The script configuration provides the SYNC_LOSS_PROFILE option for overall control over the scripts behavior when loss-of-sync occurs. By default, it is set to NONE. It also allows the user to select CUSTOM which will then read user defined commands to take when sync between source and linked destination tabs is both lost (SYNC_LOST_ACTION) and recovered (SYNC_REC_ACTION). As an example, if you might usually use this script in a single dual-display lister, perhaps you could set a SYNC_LOST_ACTION of “Set DUALSIZE 10”, and a SYNC_REC_ACTION of “Set DUALSIZE 50”… or whatever other command might give you a more agreeable visual indicator that sync has been lost. If the CUSTOM profile selected, but no commands have been entered in both the SYNC_LOST_ACTION and SYNC_REC_ACTION options, the script will behave as if NONE had been selected in order to avoid errors.
Personally, I have the SYNC_LOSS_PROFILE option set to FORMAT. As mentioned above - this option requires the user to create a standard Opus FAVORITE folder format in Preferences that change the current folder format to something visually unique. For myself, I’ve created a format that sets the background image to a large folder icon with a lock symbol on it, as well as sets the background color to an opaque-ish red color (RGB = 255, 175, 175). This (to me), is a far less disruptive style of notification that sync has been lost than what we get with the built-in NavLock feature, and was the primary motivation for me to start writing until I started heavily using multiple monitors. However, there are some caveats (see the NOTES in the next post).
In addition to the Event Handler that does the work when you change folders, the script also implements a Script Command (NavSync) that has several options to control the behavior of the event handler. These are the commands that the sample toolbar button runs:
[ul][li]NavSync ON: Explicitly sets NavSync to ON. If NavSync is already enabled for the source tab when you run this command, any existing NavSync relationship will be cleaned up and a new one set for the cuurent source and destination tabs (see the NOTES in the next post).[/li]
[li]NavSync OFF: Explicitly sets NavSync to OFF.[/li]
[li]NavSync TOGGLE: As with most Opus RAW commands, toggles between and off. Honestly, probably not super useful since any toolbar button relies on environment state to show enabled vs disabled, and the checks to do so make it more sensible to just use explicit ON/OFF commands instead. But… it’s in here.[/li]
[li]NavSync RESET: The RESET option moves the source and destination tabs back to the folder path when NavSync was initially enabled. This is safety net for in case my logic (which has some issues) falls apart and you find yourself out-of-sync even though you should be good to go. This gets you back to sanity without having to just turn NavSync OFF, then manually reset the paths in each folder tab back to the initial paths you were in when turned on NavSync.[/li]
[li]NavSync RESYNC: This is an on-demand command that does a one-time operation the same as setting the SYNC_LOSS_PROFILE Script Configuration option to RESYNC. It causes the script to attempt to recreate the missing folder paths in the destination tab that were missing and caused you to go out-of-sync. This command option can be used however many levels down you might be out-of-sync. In other words, you don’t have to do it 5 times if you’ve gotten 5 folder levels out-of-sync deep in the source tab. Just get all the way down through the folder structure you’re trying to get to in the source tab, and then run this command. It will create all the intermediary paths in between where the destination(s) originally lost sync and wherever you find yourself.[/li]
[li]NavSync STATS: This is really a debug commands to spit out the current environment variable values in effect whenever this command option is run. If you’re getting really weird results - I’d ask you to enable the DEBUG Script Configuration option and repeat whatever steps caused things to go nuts and then post the script output log. But sometimes this might be useful to work things out on your own even without debug logging without previous actions captured in-log.[/li][/ul]
THERE ARE SOME ISSUES WITH THE SCRIPT… see next post for details!
Appreciate any and all feedback!