DO11: scripting, triggering new tab by opening folder?

Would that be possible? When opening certain directories, a new specific tab (or more) would be opened in the target. Likewise, when navigating away, that tab could be optionally closed.

Basically, that would be some sort of "automatic" linked tabs. Of course the normal linked tabs are very useful, but for some actions, which aren't so frequently, the auto link tabs function would be of great help.

Yes, I think you can do that using the event that is triggered on folder change.

Very cool. I'd be thankful, if some scripting-savvy user could write that, or provide an example script over in the scripting sub forum.

I haven't played with what I think you'd need yet - but I have a good reason to do so soon that is separate from this actual use-case.

I expect a script that handles the BeforeFolderChangeData event would be what you want... in order to get access to the "path about to be read" inside the script. Not having played with it yet, I just don't know if handling that event and then opening the path in a new tab via the script PREVENTS it from still opening in the 'current' tab.

Encouraging initial results with this sample script:

[code]' OnBeforeFolderChange_xx:
' Revision: v1.0.0 (vb)
' (c) 2014 steje
' This is a script for written for Directory Opus v11.
' See for development information.

' =====================================================================================
' ====================== EVENT HANDLER: OnBeforeFolderChange ======================

' Called by Directory Opus to initialize the script
Function OnInit(ByRef initData)


' Provide basic information about the Script = "OnBeforeFolderChange_xx"
initData.desc = "Test Event Handler for BeforeFolderChange event..."
initData.copyright = "(c) 2014 steje"
initData.version = "v1.0.0 (vb)"
initData.default_enable = true

' Set DEBUG flag below to true in order to enable logging messages to the Opus Output Window
initData.config.DEBUG = True

End Function

' Called whenever the folder is changed
Function OnBeforeFolderChange(ByRef beforeFolderChangeData)

Dim path, strCommand
path = beforeFolderChangeData.path
Set objCmd = DOpus.CreateCommand
strCommand = "Go " & chr(34) & path & chr(34) & " NEWTAB"

Set objCmd = Nothing
OnBeforeFolderChange = True

End Function

' Subroutine to allow toggling of the global DEBUG variable to control whether logging is performed or not
Sub logMsg(ByRef message)

If (Script.config.DEBUG) Then DOpus.OutputString(message)

End Sub[/code]
I or someone else who continues should post a finished script in the Scripting forum :slight_smile:... Work to do here would be to provide a ScriptConfig array to allow the user to add folders/folderpaths to a list in Prefs to open in a newtab. Right now, this test script opens EVERY folder in a newtab. Test with caution...

Looks interesting. steje, but how to use it? I tested to put into a simple button, but then it throws some "'" couldn't be found message.

Ah, sorry... No, it's not a 'button' script, so that wouldn't have worked :wink:. I posted it hastily as an example...

Since the user sounded like he wanted it to be 'smart' and just ~figure out when to open a particular folder in a new tab or not - it's written as a Script Add-In. Specifically; an event handler that responds to the BeforeFolderChange event. Script Add-Ins (such as I have now attached to this post as a Script Package / OSP file) should be "installed" by dragging and dropping the script file to the Preferences / Toolbars / Scripting page.

Here's an updated version that gives you the ability to set which folder paths you actually want opened in a new tab by entering the paths into the scripts 'Configuration' - which you can access by clicking on the scripts 'Configure' button on that Prefs page (highlight the script in that page, and you'll see several buttons you can click):

OnBeforeFolderChange_OpenNewtab.osp (1.6 KB)
Note: I still need to work out how to use the FSUtil.Resolve method Jon added support for in Beta 5 in order to convert any LIBRARY paths to the physical paths. Windows adds a funky identifier in between the name of the library and the member folder... which I'm not even sure is the same from one machine to another (really appreciate the Resolve method, but also wish Opus could provide a property that just does away with that identifier all-together). So.... for now, only test this with physical folder paths. If you get confusing results, go back into the scripts configuration (again, the 'Configure' button for the script in Prefs) and toggle the DEBUG value to True... then open the output window (set utility=toggle,otherlog) to view (and post) the log messages.

More to come... feedback welcome.

How would i run that script, once i have copied it to the right place & it shows up in the prefs? I never made a button calling a script. But thanks, sounds very exciting.
Also, how would i set the trigger folder, & how to set the target folder? :bulb: :thumbsup:

Most of you people know me me to be an overly verbose SOB... so especially with multiple beers in me, I'll try to keep tis brief - but FULLY expect to fail :smiley: :

First - check out the original beta announcement on scripting, it does a pretty clear job of spelling out the different implementations for scripting support in v11.

Second - my explanation of scripting in v11 in three main parts:

Part 1 :
Support for Script Functions, which basically allow you to write scripts directly into a button or hotkey where the data you have to work with is available through the ClickData object Opus passes to the ~main-ish function defined in the button. This is essentially limited to on-demand user driven use-cases - i.e. you click a button or hotkey to make it "go". This is what I think you were expecting...

Part 2:
Support for Script Add-Ins that need to be "installed" to Opus... Script Add-Ins come in two basic flavors:

As "event handlers", where GPSoft has outlined a set of "events" that Opus will fire upon performing common actions - and which a Script Add-In can then be written to respond to. This is the case here... where among the "events" GPSoft has defined, there is an OnBeforeFolderChange event that my script registers as a handler for. I selected this event in order to be able to have my script be able to access information about the folder that is about to be opened so that I can modify the behavior that Opus would normally exhibit. In this case, BEFORE Opus opens the folder in the same tab as it would normally do - the script checks the folder path about to be opened against a set of user-configurable folder paths in order to do something different, which in your case seemed to be to open the folder in a new tab instead of the current tab... You can specify the "target folders" for which this should occur by following the directions I mentioned below about opening the Preferences / Toolbars / Scripts page (where you can drag and drop the script package to in order to "install" it), highlighting the installed script, and clicking on it's "Configure" button. That button should open a dialog where you will see two configurable script options. One is the DEBUG option which can be set to True to enable logging to the Opus Output Window, and the other is the OpenNewtabList option which - if you double click on it - will let you type or paste in a line separated list of folder paths which you would want the script to open in new tabs...

This is the beauty of the "event handler" type of Script Add-In... it registers as a handler to respond to specific "events" which Opus will always generates. You don't have to click a button to turn it "on" or to use it. It's always waiting in the background, waiting for Opus to pass it information to decide what to do with when the event it's written to respond to takes place... I'll post a few videos tonight or tomorrow for some of the things I've written if that would help.

As opposed to the "event handler" I just described, Opus also allows us to write scripts that actually add raw commands to Opus. They are a bit like User-defined Commands that you can create directly in Opus, and become available in the button and hotkey edit dialogs just as normal internal Opus commands. They are different from User-defined Commands in that they have the power of the supported scripting language in which they are written in order to control what you want it to do... You'd actually make use of these in the same way as you would any internal or User-defined Commands... in buttons or hotkeys etc. As opposed to writing the first type of "script function" mentioned above, these are useful when you want to your capability available for use just like any other internal Opus function - and might provide some additional data and methods to work with than what is made available to "script functions" via the ClickData object I mentioned above.

MULTIPLE PINTS IN AT THE MOMENT... so hope this helps rather than hurt.

Bottom line - to test whether this is of use to you (maybe I misunderstood what you were looking for)... "install" the script as instructed via Prefs, then click on the scripts 'Configure' button... Double-click on the 'OpenNewtabList' option shown in the configuration dialog and type in several folder paths. What should happen is that anytime you click on the folder specified in the full folder path(s) you add to this option, the folder should be opened in a new tab without having to explicitly do so using a button or qualifier key, etc.

Is this not the main part of what you asked could be done?

HOLY HELL, how do so many words just come spewing forth......................................?

Cheers! :smiley:

Yes, i think it is. But i'm still not sure about the syntax:

I guess i don't have it right in some way. The upper path i'd suppose is the path that triggers the command (?), the lower path is that one, that should open in a new tab, preferably in the other file display, because the whole idea is to have various paths opened on my USB drive, which would open the according target paths, to which i want to copy things.

By the way, i used the checkboxes to activate the scripts, but until you pointed it out, i didn't click on them to find, that there is a whole configuration dialog to pop out. :smiley:

Steje, i see now, what the code does. It opens those paths in new tabs, whenever i visit them, which is also quite interesting, because there is no way to do something like that in Opus without any help of the scripts.
What i was actually suggesting is, that when i open folder A in, let's say the right file display, it would trigger some folder B in the right file display. Following use-case: i used to carry stuff on my USB drive to some othe computer
once a week.

The idea was, if i open N:\Films on the USB drive, the according directory on the computer's hard disk would be opened in the target file display (like S:\film collection), so i can copy the items right away. Also, when leaving that folder again, the according tab would be also automatically closed, "cleaning up" the tabs, so to say. Until now i have some static tabgroup, with linked pairs of folders for images, films, music, programs & documents, which i used to load when i want to copy over to the harddisk. So the idea was basically to have some "auto-linked tabs", which i see as "dynamic" mini tab groups, or pairs, being transient events.

I think, there would be even more possibilities for scipts like that along the line, like opening specific tabs based on the selected file types. Imagine, pointing on some new .avi or a group of .avis in your download folder would open your movies folder in the target file display. Anyway, thanks for this new script, which shows, what completely new dimension of functionality in Opus is available from now on. :thumbsup:

I have to correct this: "that when i open folder A in, let's say the right file display, it would trigger some folder B in the left file display."

So I guess I completely misunderstood the specifics of what you were asking for :wink:.

I'll think on what you've said... I suppose you could use the same 'Configure' button in order to enter in a "pair" of folder paths on ONE LINE, which I'd suggest you could separate from one another using a special character (maybe a pipe symbol == |) so the script could understand how to break up the single string into two linked folder paths.

That's easy enough... but I'll have to think some more on the whole auto-close cleanup thing you're talking about.

[quote="steje"]So I guess I completely misunderstood the specifics of what you were asking for :wink:.[quote]

Yeah, sorry steje. I should've elaborated the whole idea a bit more. Thinking about that idea, there are even some more things to consider, like having a possibility to suppress oder turn off that function, in case it is not needed
in a special situation.

Sounds like a good idea. & like i said, maybe some toggling function would be needed, in case the linked tabs action isn't needed in a situation. Like i said, the whole idea is to make it easier to copy stuff on a different system to their
appropriate targets.

Well, that was only some idea, but i think it makes sense. Like we have the new automatic toolbars, that can be configured for special locations, which also auto close, when leaving that location, this would be some script based automatic
folder pairs. I appreciate your help very much. :bulb:

I'm really happy with the new scripting interfaces... but what you just said about automatic toolbars and such reminded me of something I've commented on a few times that I'd really like to see in a future Opus release at some point... that being:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<< slight departure here >>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Just as we now have a drop down to select a toolbar to turn on automatically in a particular folder format... I think it would be real useful and a bit ~cleaner to have another page in Folder Formats where we can specify any arbitrary command or script. I would expect such a page to look alot like the standard Command Editor for buttons and hotkeys.

My rationale is that you can then be more prescriptive in the use of scripts to do stuff like what we're talking about here, but linked to the Folder Format backing the desired folders you want this sort of behavior for... Rather than the way I was going about this, where I register an event handler which Opus will ALWAYS invoke on folder changes whether the script has any work to do or not. If we could execute the same sort of functions as part of the folder format kicking in... well, Opus is already ALWAYS checking to see if the folder you're switching to has a folder format associated with it. So it seems more economical to me to do things in this fashion - particularly in use-cases where you might only want an OnAfter/BeforeFolderChange related action on a rather limited number of folders. It might be less prone to unexpected results particularly as we all get our feet wet with using these great new interfaces more and more. Even in just the automatic toolbar case, I'd see the 'option' to run your own specific toolbar toggle command(s) as giving you some more flexibility than the user-friendly drop down we have now offers. For YOUR case, you also get to work in a dialog you're already familiar with to setup what you want to have happen when you open one of your ~trigger folders. And aren't we all already used to doing that via Folder Formats already?
<<<<<<<<<<<<<<<<<<<<<<<<<<<<< /slight departure here >>>>>>>>>>>>>>>>>>>>>>>>>>>>

I digressed a bit, though it's fully relevant to what you want to do... I'll go ahead and post a separate FR thread to hash that out if GPSoft is game to discuss. I know they're looking to focus more on refining what they've already developed as opposed to adding entire new interfaces for customization at this point, but I'll put it ~out there.


For your case, the pairing of folders is easy enough to do. For the automatic tab ~cleanup piece - I'll have a look at the OnCloseTab event to see if we can pull some sort of Tab data for the 'other' folder you want to be paired with your primary/trigger folder. Let me make sure I now properly understand what you're looking for though before I hack any more code together :slight_smile:.

So, you want:
[ul][li]To be able to set up an association between two 'paired' folders. Presumably in a way that let's you define a primary/trigger folder - that when you open triggers the 'paired' folder to be opened automatically in a new tab in the ~other file display.[/li]
[li]Some sort of smart tab "cleanup" such that when you close one of these 'paired' folder tabs after finishing your work the ~other folder tab it's paired with is also ~auto-closed?[/li]
[li]A way to 'toggle' the automatic opening of the 'paired' folder - so that it happens only when you want it to.[/li][/ul]
I avoided using the term "linked" above for a reason and used "paired" instead just because I want to make sure I understand the behavior you want without dragging other normal Opus concepts into the conversation. THAT SAID, linking the tabs may very well be appropriate here... I'm also thinking perhaps GPSoft might consider adding an additional property to the Tab Object that can indicate tab link state... For instance, a property like that could be 0, NULL or False (whatever) if the tab being examined has not been linked, but otherwise provide the Tab collection data for the tab it's linked to if it is in fact linked. That'll let me not have to worry about whether or not the folder tabs you want to be paired/linked up with each other are the 'active' tabs on either side of the display or not at the point when you decide to close one of them... I could then just check for the 'link' property on tab close event and explicitly close the correct tab on the other side of the display.

I'll start a new thread asking them about it as I don't expect them to see this ask buried here in this thread :wink:. ALTERNATIVELY, maybe GPsoft could also consider some sort of qualifier key control when closing a tab that is linked to another tab... say, you hold the Alt, Ctrl, or Shift keys down when closing the tab in order to tell Opus to also close the tab to which it's linked. I'll exhaust the options we have available to us now first - since any of what I just suggested might need additional enhancement from GPsoft.

[quote="steje"]So, you want:
[ul][li]To be able to set up an association between two 'paired' folders. Presumably in a way that let's you define a primary/trigger folder - that when you open triggers the 'paired' folder to be opened automatically in a new tab in the ~other file display.[/quote]

That's correct. Maybe some extra parameter would make sense for those paired folders, to set them "bidirectional", so that folder A in the list would trigger folder B, & vice versa. So, let's say, the normal syntax would be (as an example, just to show what i mean)

D:\folder A; G:\blah\folder B, meaning that visiting or leaving path A would trigger path B to be opened resp. closed.


D:\Folder A; G:\blah\folder B; $both would work in either way, like i said above. I think that would make sense, if there are two "buddy" folders, or paired folders / "smart folders".

[quote][/li][li]Some sort of smart tab "cleanup" such that when you close one of these 'paired' folder tabs after finishing your work the ~other folder tab it's paired with is also ~auto-closed?[/quote]

Yes, exactly. I think that would make a lot of sense, not to leave the partner folder opened after the action is done. The main idea behind this is always aimed at comparing or "checking" two folders ("did i copy that new program already to my USB drive?"), or copying / moving things in both directions. Those are the main actions for this use case, rather than normal browsing. That's why i think that the $both parameter would be quite useful, although you might as well simply could make two version of the paired folders, from A to B, & from B to A, which would give you the same effect.

Maybe something like holding shift while navigating back from one of the paired folders would make the partner folder NOT close, but that's just a side idea. Also, changing tabs on one or both sides shouldn't break the tab pair up, unless you navigate away from one of the original paired folders.

[quote][/li][li]A way to 'toggle' the automatic opening of the 'paired' folder - so that it happens only when you want it to.[/li][/ul][/quote]

Yes, that would be good, although i'm not sure if it would be necessary anyway. The paired folders are quite transient, so they might not get in the way at all. They would clean themselves up. But nothing against the possibility to toggle it off by some extra command, suspending the whole script, if thats not a problem. It would be quicker than toggling the script off in the preferences.

I agree, this all has to be taken into account, as far as i can judge as a no-programmer.

Sounds reasonable. I like linked tabs, & use them a lot, including the new commands to set them quckly, although i seldomly have more that a dozen or so tabs open altogether, even here on a 24" monitor. That's why those "dynamic" or paired tabs would be interesting in my opinion, as an addition.


Check out the post in the Scripting Forum: DO11: Script to open/close related folder tabs automatically

It's rudimentary at this point as we're still unable to do certain things that would make it a bit smoother to use like be able to re-use existing tabs (NEWTAB=findexisting) as well as be more selective in closing the linked tab (like holding a qualifier key down). I'll be posting some feature requests to GPSoft later to see if some of this can be expanded upon.

At the moment, if the script is installed, it's active. I think you mentioned being able to disable it. I'll have a look at that after you give some initial feedback...

Steje, thanks a lot!! From my first impression (got to finish my laundry first, before i can check the details :smiley:) it works just as intended. I think, this will get my first heavily used
script, because i know at least one dozen folders to be "connected", "tunneled" or whatever we could call this. I'm looking forward to test it later this evening, & i will report back,
if questions arise. Great work (& of course from the GP team, too)! :thumbsup:

Hey abr, sure thing... sorry it took so long to work out. I had stopped several times and hadn't picked back up on it immediately after GPSoft made some further enhancements - mainly due to being enormously busy at my job.

FWIW: and not that anyone HERE has made any complaints... but just the same, for anyone who wants to claim that GPSoft doesn't listen enough to users, let's tally up the changes they made JUST to allow this script idea here to work as hoped:

  • allowed script config arrays (now vectors) to accept variable sizing so that users could add in multiple lines (rather than have to pre-size the array to a particular (and limiting) size). This is used in the script option to allow users to add however many pairs of folder paths they want the script to operate on.
  • added new properties to the Tab object (linktab) so we can examine a tabs status re: linked states. This is used both to handle the opening of the related folders, as well as to figure out whether to auto-close a tab that is linked.
  • added multiple helper functions to make common file system interactions easier than doing lots of things in-script with filesystem object calls (FSUtil.Exists). FSUtil.Resolve in particular is used widely by this script to resolve any virtual paths (like library based paths) to the true physical path in order to be flexible in terms of how the user can both enter their folder paths into the config options, as well as actually navigate folders in the lister. Without this one method... I was going to have to write my own helper function to do all the resolution. Happy to NOT have had to do that...
  • added support for Go TABLINK in a script to link tabs based on script accessible tab handles... key to this scripts ability to link the tabs.
  • added support for Go TABCLOSE NOSCRIPT option to prevent recursion of the tabclose event.
  • added support for Go TABCLOSE=<tab_handle>... where other ways of closing the linked tab was proving very inconsistent... this was an explicit change that makes it work predictably every time now.


Amen to that...! I usually try to bolster my arguments for enhancements to Opus by saying why I want things to work a certain way, and add to that how I think it may benefit others. Strength in numbers, ya know. But many of these (while still useful to others) were one-off requests - posted purely as knee-jerk reactions during my attempts to get thinks to just basically work. I'm sure they expected that the scripting interfaces would need to be enhanced over time as people proved ready and willing to actually make use of them, and as robust as the interfaces were right out of the gate with the first beta, man... there was quite a bit of re-work done during the beta on the scripting interfaces alone!

So a BIG round of applause for GPSoft's support of our scripting endeavors so far!!! And now... several additional feature requests as a reward for a job well done :slight_smile:. LOL...