Confirm Dialog Variables Modifiers Arguments

Is there a way to use the @confirm: modifier to display the value of a given variable?


@confirm: {filepath$}

or some other way to inspect variables?


A couple of ways to do it are near the end of this thread/reply: Scan folders and copy/move a directory if it exists

So dopusrt is the answer?
dopusrt /ArgsMsgBox {filepath$}
presents a dialog or message box with the expanded var?

Here is what I have going on:

(works great for quick temp backups of source code materials)


@set vSPath = {sourcepath$}
@set vFName = {file$}

@confirm: ( Archive Selected Folder to _arcs ? )


Copy ARCHIVE CREATEFOLDER="{$vFName}_{date|yyyy-MM-dd}@{timeu|HH-mm-ss}" TO "{$vSPath}_arcs"


Can I display a var within this little menu routine somehow, instead of the static message I now have, or is my only option to use dopusrt as a debugging tool in the creation of these little routines?

If you mean you want to do the expansion in the @confirm line then, no, I don't think that is possible. The @confirm line is processed before any argument parsing happens, I think.

This is quite old, but still a valid idea.

I try to use {sourcepath$} and similar variables in confirm dialogs "all the time", but unfortunately they never show up expanded, bummer! o)

Seems less important now we have scripting.

Don't know if this will work in every scenario, where the @confirm modifier works, but yes you're right, there's scripting! o)
I just put this script together that mimics the @confirm and gives some more room to play with. Thanks for making me do this finally! o)

  • supports custom title, message, buttons and icon (all parameters optional)
  • supports placeholders for the number of selected items/files/dirs {#selitems$}, {#seldirs$}, {#selfiles$}
  • supports inserting of of all DO variables (global, tab or lister-scoped) and linefeeds ("\n")


Confirm MSG="Really copy {#selitems$} items from \n[{sourcepath$}]?" BUTTONS=Yep|No TITLE="My Title"

Command.GUI_Confirm.js.txt (6.76 KB)

I was thinking more along the lines of doing the dialog and conditional logic in a script, rather than writing a replacement confirm command for non-scripts.

As soon as you want conditional logic or any kind of user interface, I think it is a false economy to avoid scripting rather than dive in and use it directly.

(For just checking what things like {sourcepath$} return, I generally switch the command type to DOS Batch and use the echo command.)

As much as I dislike all the issues with the old-school button-syntax, it's so damn fast to write and it still provides a very efficient way of doing things in very few lines which would require a page or two of scripting. So I just cannot let them go! o)

Pulling up a script ends up in browsing docs or looking into other scripts most of the time, a script-addin seems to be perfect here, to have a more feature rich requester in the other, "fast button" world, don't you agree? Scripting is versatile and appreciated, but as said, I find it get's quite verbose for smaller tasks. The re-usability is also not there.

Because of all this, I even did a proof-of-concept WSC recently, that wraps the verbose scripting into a more easy to use command-set (basically global functions, that are context aware), so you get the simple syntax from the buttons, with the full power of the scripting capabilities added ontop - you just don't want to put together 50 lines of code everytime you need a confirmation dialog that can show the sourcepath, don't you?

This is a small example of how the "RapiDO" WSC works (what you think about the name? o):
If DO would provide such a fast API by default, I would not look back to the old buttons. With RapiDO you don't really "script", you just write commands as before, but at the same time you're in strong control of flow, environment and logic, which is where the old button-syntax really lacks fun and niveau. For sophisticated scripting, you still can dive deep into clickData.func.sourcetab etc. and pull out what is required.

function OnClick(data){
	foldername = Input("Folder to create:", Now.format("yyyy_mm_dd hh-MM-ss")); if (!this.foldername) return;
	backuppath = Alias("backup");

	Copy('TO "{$backuppath}/{$foldername}"'); 
	if (KeyDown("shift"))
		SetAttr('SETATTR R FILE="{$backuppath}/{$foldername}/*"'); 

Compare to the regular button syntax, RapiDO is very near:

@set foldername = {dlgstring|Folder to create:|{date|yyyy_MM_dd} {time|HH-mm-ss}}
@set backuppath = {alias|backup}

CreateFolder NAME="{$backuppath}{$foldername}"
Copy TO "{$backuppath}{$foldername}"
SetAttr SETATTR R FILE="{$backuppath}{$foldername}*" [/code]
Notice, I left out 2 two lines where RapiDO is initialized (could be done by DO natively) to not detract. I admit, I'm not so sure about how the Copy() and other internal commands are handled parameter-wise right now, but the thing is, that some function-"layer" like this, could combine the best of both worlds. All the ready to use internal commands and especially the vars like {sourcepath$} and {time} etc. in combination with the various modifiers you invented over time (to get the item-name only, it's parent-path etc.), really allow you to do things very fast, without tinkering with an object model and hiding what's happening in a lot of code, which is not necessary for most of the tasks.

To not give a false impression, the deepness the current scripting api offers is appreciated, it's just not a replacement for the old button syntax.
The latter seems to be unsupported to some degree since v11 is out. "Scripting!" is the answer to many questions since then, but while scripting is fine, it also hides a lot of DOs functionality, which then needs very advanced users or software engineers to be able to take advantage of it.

The regular "I daisy-chain some commands and it works!" person, will not dive into programming and mess with properties and types of variables.
My thinking is, that people will get behind, which were not afraid to put buttons together in the past. Fully relying on scripting raises the bar for anyone to a whole new height. DO is very "high" already, it is already overwhelming for most in its current iteration. I think the only way to fight this is consistency and intuitive use wherever possible. A set of functions that mimics and rebuilds the old button-syntax would be an easy transition for everyone, it would be the actual replacement for what seems to be unsupported/depricated more or less.

It's not unsupported nor deprecated, but when someone posts a question asking how to do something with traditional button syntax, and that something isn't possible, which makes most sense? To say "you can't do that now, but we'll put it on the list to look at adding that ability in the future", or to say "you can't do that with traditional button syntax, but you can do it with scripting!" ?

Of course the latter makes total sense (pointing to the scripting), but there is a difference between "it can be done with a script, just find someone doing it or learn how-to yourself" and native functionality which will work for everyone in an upcoming release. So I still get the impression the old button-system is kind of unsupported for some time and iirc Leo also said so somewhere (?). Having the scripting API at hand, does not solve requests. I guess, that's what this boils down to.

So, that's why I was trying to showcase a possible bridge between the two worlds, people could help themselves more easily - any comment regarding this approach is still appreciated. I also provided a solution for the confirmation dialog issue which works here and there and now, but I actually don't get why "doing the dialog and conditional logic in a script" would have been any better.

I'm not quite sure what your suggestion is. Are you saying there should be a series of exported functions (e.g. Input and Alias) as a simpler interface to the existing scripting objects/methods?

My suspicion is that this probably wouldn't help most people. People who know how to write scripts aren't going to be put off by having to look at the manual, and people who don't know how to write scripts aren't going to be helped by having a series of simpler functions they can call - if they don't know scripting, they don't know scripting.

Also don't forget that often Leo's response that "You can do that with scripting" is followed up by him actually writing the script for someone (provided they have linked their account). There's no point just doing that first since the user may actually be able to do it themselves but if they come back and say "I don't know how to do that" then Leo or someone else usually obliges for them.

Yes, I imagine all basic functionality to be available without the object-chaining and passing around of references. These exported functions as you call them, shall be context aware too, so that {sourcepath$} resolves automatically. People end up with a foot in the door to the scripting world, while basically using what they are used to for years.

You might be right, but if people can lookup the COPY command and its switches, and then there is the equivalent of Copy(), using the same syntax, they suddenly know. It's much more easy than using onClickdata.func.Command.RunCommand() and manipulating the object with Clear/AddFiles() beforehand. In the not so long run, you could end up with a proper replacement for the standard button type, while also providing much more depth if needed and wrapping up/dropping stuff from the past.

I know, and I think it could be part of the issue, since such solutions are not available to everyone. If person A writes snippets for person B, person C downloading the latest release will not benefit from the efforts person A invested. Who is going to even know about this new @confirm replacement? Few to no one. Currently, the out-of-the-box or native functionality does not broaden with solutions in scripted and unmanaged form.

That's another reason why I think "it can be done with scripting!" is "difficult" for some requests. Can you understand what I mean, to some extend at least? o)

Both probably make sense. :slight_smile:

Scripting is probably a wonderful addition, but I have to agree with tbone that there are people, probably including me, who might use the simpler syntax, but will never learn or use scripting (including the underlying language(s)), not because, as an ex-programmer, I'm not capable of doing it, but because, at this point in my life, I probably simply won't invest the necessary time and effort.

If you feel it's best for you to cater to those willing and able to invest the time and effort, that's fine, but I think its true that you will lose some people.

It's not really that we're choosing one over the other, but that certain things are more suited to scripting than basic commands.

Anything with a UI and conditional logic is the realm of scripting now, in our eyes, or in my eyes at least. It can sometimes be done using basic commands as well, but it's just so much better, and easier, after a very small learning curve which should be fairly easy for anyone who already knows about things like variables and conditional logic. And basic commands so limited in that area that it's almost inevitable that you'll run into their limitations and want to use scripting anyway, so it makes sense to encourage people to go there from the start, to save time.

Yeah - there's no single "right" answer here from the user perspective I think. I am as ready and willing as anyone to turn to scripting. But particularly from the perspective of trying to help ~other Opus users, I really (still) just sometimes want a 'simple' method that I can suggest to a non-script savvy user that they can accomplish on their own without waiting on me to write a script.

I kind of felt that way with with the recent thread about CBR/CBZ files where my "opinion" was that @ifpath should absolutely be able to detect if it's inside of an archive or not... and still - I think it just "should". But in the end, I did like you suggested and wrote a script... and got better functionality out of it than I would have gotten if I'd have just been able to use the simpler method using native commands and such in a regular button.

So for me, I'm FINE with scripting often being the answer - I just hope non-scripting methods don't become neglected 'because' we now have scripting.

@tbone - with your critique of script solutions not enhancing the 'out of box' experience, I think you're ignoring the level of reliance I think most users have come to have on the Resource Centre here. In the world of extensible web browsers (who uses Firefox or Chrome without extensions???) and other plugin ready applications, I think most users that would gravitate towards Opus in the first place (often 'power users') are more inclined to looking for add-on enhancements than has ever been the case, so I don't see that as a 'huge' drawback. And you could probably take a poll to see how many 'new' users are even functionally ready to write complicated buttons with things like command modifiers to begin with. That's very often just as much the domain of assistance from the forums as well, just like scripting.

That said, I "do" agree that maybe more could be done to DRIVE users towards solutions that have been community developed. We have the link to the script add-in forum in the Scripts page in Prefs... but I wonder what GPSoft would think of making it a bit MORE obvious - particularly for new users... For instance, some apps build additional awareness into their setup/installer or regular app UI's. I'm thinking of web browsers and packages like Cygwin, or various media players like Zoom Player or foobar2000, where you can see a list of additional packages, or 'official' plugins that can also be installed. As it is, the only people who would find out about the link to the Script forum are people that have ALREADY become aware of scripts and are looking at that page in Prefs - or new users that are just at that point in their exploration of the Prefs options as they're learning.

For Opus - I'm wondering what appetite GPSoft might have for integrating scripts THEY write (or possibly 'periodically' review from user submission for worthiness and stability) into a notice that could be displayed during product install, and perhaps into the Help and Update Checker interfaces. They could make stable script add-ins that they "approve" directly available for download and installation into Opus from the same post-install series of questions like whether to let Opus handle pictures, archives, or ftp, etc. As well as possibly Prefs AND the update checker, and download and install them directly from the product UI.

Back ON topic... I'd been intrigued by one of the Global Variable tools one of you guys wrote awhile back... Particularly while writing scripts that rely heavily on environment variables for execution control - I was think it'd be nice to have something to quickly examine current Opus vars.

I think I'm going to tweak that script and create my own 'stej-ified' version, and will add in expansion of built-in Opus control code values - and write it in a way that can accept some custom messaging for use in prompting (like @confirm) before taking action - when called with some arguments to do so.

For quick variable peeking, the "Say" addin may be helpful (prints to script console), it also resolves global/lister/tab scoped vars. That's where I quickly grabbed the code from to make it work in "Confirm" as well.

It can do that already! o) There's a parameter for msg, title, buttons and.. items in the version not uploaded yet.
What it cannot do is resolving all of DOs other control codes, but when run from button-old, this is done by DO before any text gets through to the command, so it's not necessary for most situations.

Just pay attention when working with path/control placeholders and script commands, the vars seem to be resolved only on the first script command, any following command will not receive resolved vars correctly.

But, you can prefix any script command with the ForEach hack I came up with as an emergency solution. The real one is not there yet. With that "hack", vars will be resolved everytime. This is a usercommand, it's helpful if you want selected items to be processed one at a time by a scriptcommand.
Usage: ForEach CMD=MyScriptCommand SWITCH01 PARAM01="{file}"

<?xml version="1.0"?> <button backcol="none" display="icon" textcol="none"> <label>ForEach</label> <template>CMD/R</template> <icon1>#usercommand</icon1> <function type="normal"> <instruction>&amp;CMD&amp;</instruction> </function> </button>


Cool... I'd only looked at it in passing and hadn't actually tried it. Probably should have done that before my FLURRY of holiday vaca script updates.....