which works for the not holding ctrl -> internal/DOpus command section (the second @script modifier seems to have no effect here, I see no difference with any value or indeed omitting it), but once we step into the JScript section, the next "@" directive throws a non-descript Error at the line in question, pointing to the colon.
The JScript section itself also works if I remove the attempts to step out via "@" modifier after that, too.
A thought I had was that maybe the @keydown modifier only works if I set the @script language back to normal ("internal"/"DOpus"/...?)
Of course I was quickly disillusioned of this, but looking up the documentation, I saw no indication of what the possible values of this modifier could be.
Q1: Is there a way to set the script language back to internal DOpus commands?
Q2: Is there a way to make use of different scripting languages, including "standard" (DOpus or external), in one button? Ideally subject to other modifiers?
It seems like, if there is no further implementation in place to make this work, the issue could be resolved in ordering @keydown (or other modifiers) higher than @script and only parsing script contents up to the next modifier as script contents.
The documentation of the @script modifier could do with some clarification of which values are acceptable. If it's somewhat dynamic as dependent on something like the Windows Scripting Host, this should be noted as well.
Once a button uses scripting, there's no need for simple conditional logic like @keydown (and it won't work anyway). Instead, the script can test if keys are down itself and do its conditional logic using the scripting language's much more powerful constructs. The state of the keys is given to scripts via the OnClick event (and can also be obtained in other ways).
Scripts can run internal commands, too. Most of the examples show how to do that.
The drop-down in the button editor lists the available scripting languages installed on your system. It's self-documenting.
In fact, you shouldn't normally use @script directly; the button editor will add it for you behind the scenes.
The only times you typically need to add a @script line yourself is when using scripts in more obscure places, such as filetype events. (This is more an oversight on our part. We've just never updated the button editor to show the newer scripting controls when editing those things. But it also rarely matters.)
If you install additional ActiveScripting languages then they'll appear in the drop-down list, although we strongly recommend sticking with the two that are built into Windows (JScript and VBScript) because it means you can share them with other people (no one wants to install a third-party scripting language just to run one Opus script) and because ActiveScripting is such a loose API, and other languages can do things so differently, that you'll often run into problems with other language's quirks, while we've made sure everything in our scripting API works with JScript and VBScript.
Opus's built-in commands and simple @modifiers are not considered "scripting" here, so there's no "Internal Opus scripting language". If you're using simple commands and @modifiers on their own then you aren't using scripting at all, at least as we define it.
Aah, so that's designed to be like a flag/boolean?
This also might do with an explicit statement in the documentation)
Yeah, I get where the concept is coming from; that's how I imagined things probably were under the hood.
However, there are use-cases that would make an ordered context-specific approach as imagined above hugely convenient, a big nice-to-have.
Yes, I routinely call internal commands or use the provided arguments.
But wouldn't it be so much nicer if the above example was possible?
especially for seamlessly integrating things like do stuff based on {dlgstring|...} in one command to execute, directly using DOpus internal commands, alongside explicit scripting, would be so neat!
That is true only when the documentation points you to that fact
Just leaving these 2 cents here as feature requests and opinion
I think it'd be really complicated and confusing (both for users and for us to implement), because you would have control flow going back and forth between two languages. Script variable scope would no longer make any sense, in particular. And you'd only be able to jump between languages outside of loops, which wouldn't be very useful. I don't think you would gain anything useful.
Scripts are more powerful than basic commands, in terms of logic and branching and doing things with the OS or other installed software, and scripts can run basic commands as needed. Once you're using a scripting language, the conditional logic/tests from the non-scripting side of things are accessible within the scripting language without having to go back and forth between languages. Mixing the two in one button would just complicate things.
Scripts have their own ways to show dialogs/prompts and then work on the inputs. You can also use {dlgstring} and similar within commands that you run from scripts.
You don't need to read the documentation to see the list of languages in a drop-down. You just need to look at the drop-down.
But the documentation also says, in the first paragraph at the start of the Scripting section:
For example, VBScript and JScript are built into Windows, and many people are already familiar with them from the web. Other common languages like Perlscript and Python can be obtained from third-party providers.
So I think what you're asking for is already there. You just didn't look in the right place.
Hmmm, I somewhat disagree: The docs are concerned with the choice to be made for the context of the script editor.
AFAICT, it is valid (though, yes, I guess discouraged) to embed scripts within a standard function (Opus or external) choice.
The equality of the top level choices and possible values to be used within a standard function via @script is loosely implied but not documented on either the Advanced Command Editor page or the Command Modifier page.
Of course, that's fair. Just wanted to leave my voice here to be considered
Looks like it, at least to the degree of inference necessary as per the beginning of this reply. But also: Wouldn't the world be a better place if documentation everywhere placed references to relevant related aspects about the features currently being documented?
It's anachronistic, and I don't think the documentation tells you to do to that anywhere except with things like filetype events (where the editor doesn't have the script/language stuff), and embedded Rename scripts (where a script is included after the Rename command, and the script isn't what the button itself runs; the button runs the Rename command and the Rename command runs the script).
The documentation for @script says:
This is mainly used for embedded rename scripts, because otherwise the script language is selected via a drop-down at the top of the script editor.
The only other mentions of @script are on the page about Embedding Rename Scripts, a mention on the Script Dialogs page saying you don't need to use it, and a passing mention in the Advanced Command Editor page which I'm going to remove as it's out of date.
In older versions of Opus, you had to type the @script line by hand and there was no UI to set the button to script mode and choose the language. But that was many years ago. Where are you getting the idea you need to know the list of languages or type the @script lines by hand today? Are you editing button config files by hand? Or reading some really old threads without realising there's a UI for this now?
Oh I was just trying things out in order to find the most convenient way of writing button scripts or commands. I remembered that @script was a thing and "mainly used for" didn't discourage me enough to explore that avenue.
Sorry for being so verbose, I was inebriated that day
