Hello,
Noticed the Marker and Dynamic Buttons section in the DOpus Manual, but didn't see anything about how to use Jscript to create my own Dynamic Buttons that fill in a Marker block in the menu. Fairly familiar with the forum content and did some searches but didn't see an obvious path forward.
Thanks for your help,
Scripts cannot generate lists of buttons at the moment.
Official support for this would be awesome! o) Perhaps by some "OnToolbarOpen()" hook directly in the button to generate menu buttons etc. or by some global OnBeforeToolbarOpen() to update the *.dop file (and contained buttons) before DO reads it.
@ouwen
You actually can alter toolbars and buttons by directly touching the *.dop configuration files of DO. Toolbars need a "toggle" afterwards to reflect the changes (if DO is currently running). There is GUIEx to help with this. This script command has a "TOGGLETOOLBARS" option. Run "GUIEx TOGGLETOOLBARS" and watch all toolbars go away and reappear updated.
Command.GUI_GUIEx.js.txt (22.7 KB)
I made this because I maintain DO buttons which are used by several collegues of mine at work. It's a pita to tell and help people to update their buttons regularly. The command above is part of my investigation to automate all this, not there yet though. o)
The main thing stopping us adding this (other than the possible effect on performance it might have) is the problem of how a script could trigger an update of the generated buttons. Obviously it depends what you would want to use it for, but presumably the list of buttons the script is going to generate wouldn't be static (otherwise you could just configure them as normal buttons) so then there would need to be some way for Opus to know that it needs to call the script to get it to regenerate the list of buttons. So far we haven't come up with a good method for that.
For buttons to be generated directly in a toolbar (to fill an empty toolbar with buttons in the extreme scenario), the moment the toolbar opens sounds like it would do the job?
For other type of buttons (menu-buttons e.g.), which already have their place in a toolbar, but need dynamic filling of entries, the moment you click those buttons could be right to update those.
Too naive thinking? o)
This dynamic button generator thing, could possibly also have some "when to update" configuration/callback?
You could pass information wether the button is to be updated because it has been clicked or because its toolbar opened and let the script decide if the update shall run by returning true/false, after evaluating if button-content is expired/unset).
If it's a popup menu then scripts already have a way to do those.
Most toolbars stay open, so only updating dynamic buttons when a toolbar first opens would have limited use.
As Jon says, scripts would need a way to tell Opus "hey, the things that determine which buttons I generate, and what their labels and icons are, have changed" or the whole thing isn't very useful.
e.g. If you want a script that changes buttons depending on the selected files. Or the current folder. Or based on the time or date.
Depends on the usecase. I build buttons that are used by my coworkers. These contain current working paths, latest build directory, two dozens RDP connections, specific scripts launched by hotkey etc., if all these buttons update whenever somebody closes/reopens a lister.. What time saver is that?
Currently I say: "You find it in button-x". The coworker: "Nope, it's not there." Me again: "Well, than please update the button.", The coworker: "How do I?" Me: "Ok I'll do it for you once more, but please pay attention.." <Meanwhile: Coworker looking at birds outside the window.> - You get the idea? o)
So I actually wasn't thinking about dynamic button content depending on any item selection state. That surely has some decent usecases too, but is more on a high sophisticated, functional level. What I have in mind right now is easier maintenance/replacement of single buttons and some way to update entries in menu-buttons (by a populating script or some auto-button-import thing). This does not require updating in very short intervals. It still saves a lot of manual work for me and others.
I'm also thinking of buttons that come as bundle with scripts, once such a button is in place, it could offer what the script likes to expose (new functionality, additional entries etc.).
I think it would be fine to have slightly different rules & expected results depending on whether the scripted button content is on the root of a toolbar or under menus/buttons off the root of the toolbar.
For content 'on the root': opening the toolbar for sure, which should also cover events that automatically turn toolbars on or off like toolbars saved in layouts, or content type driven changes. And though some might miss it - I think for root level content, there are still plenty of useful benefits to be had without file selection driven content update support. But there's probably already a performance question here - depending on how long a script takes to do it's work to figure out what to show...
For content 'off the root', like under a menu or menu button: I wonder what the performance would be like updating the content upon opening the menu/menu-button, with or without file selection awareness. But maybe file selection driven updates work under a menu. But I think you have the same general performance question here as well re: how long a script takes to decide what content to show.
I do think it would make sense for such a script to allow a callback function that Opus can invoke, as long as the callback can be made available to other scripts. This way, we can update our own content after performing a scripted action somewhere within the button, but also perhaps in 'other' scripts (let people decide based on their performance experience). For instance, people could configure an OnAfterFolderChange handler to call a toolbar/buttons callback function to update itself. This way, for well written or otherwise fast-acting scripted toolbar content, it can be handled on a script by script basis whether or not to try updating on an aggressive schedule like folder changes...
One of the things people have asked to do is be able to change button labels, icons or pushed-in state in reaction to something happening.
When toolbars or menus first open is one of the times when things would need to be updated, but it would not be enough on its own.
I believe that better that create dinamic buttons would be create buttons from a script, that's it, this button has no differences from the manual created, i know and I did some scripts that do this by modifying directly the toolbars files, but is a very dirty way and will love to see an "official and more practical "
I also wanted this feature, and I thought about it :
A kind of database of variables, maintained by DO, with just the name of the variable and the value.
Then, in the buttons, it would be cool to set this variable in the name of the button, or in the path of the icon.
Those variables would be easy to modify within scripts.
The only event to detect is when a variable value has been modified or a new variable has been created, to launch the toolbar updates.
Does it make sense ? 
What's the use-case / example that you're thinking of? When/how would the script update those variables?
I wished to make a button, that just paste the clipboard content to a predefined alias.
Where it's different, it's because I wished to let the user choose the place where points the alias.
Ex : An alias named "path1", pointing to "C:\My Movies\Movies 2016".
So one button to let the user choose where points the alias :
Favorites ADD=alias NAME="Path1" PATH="{dlgfolder|Choose your path to path1|{sourcepath}}"Here we could add some code to change the value of a global variable named for example "LabelPath1", with a value made with the path1 (for example "Movies 2016").
This value would then go to the name of the button, with something like {LabelPath1}.
I hope I'm understandable, it's not the first time that I fight with my english (and I often lose ).
Thanks, that makes sense. (Although the script would not know if you changed the alias via Preferences, until the next time it was run, so the label could go out of sync.)