I'm having a little attempt to crack this topic, because I assumed it is possible: Command.results.result is always -1 -> Command.results.result is always -1
So I created a new script command SetVariable, which is able to set a global variable from "outside".
function SetVariable(data) {
if (data.func.args.got_arg.name) varName = data.func.args.name; else return;
if (data.func.args.got_arg.value) varValue = data.func.args.value; else return;
DOpus.vars.Set(varName,varValue);
}
[/code]
But when SetVariable is used in a script button, the variable is not available in the script, right after setting it by using dopusrt.exe. So the DOpus.vars collection, does not reflect the change to the global variable store, the script in the button needs to run twice to "know" about the newly added variable.
Button-Script:
@script jscript
function OnClick(data){
var vars = DOpus.vars;
if (vars.Exists("XCopyResult")){
DOpus.Output("XCopy result (before): "+vars.Get("XCopyResult"));
//vars.Delete("XCopyResult");
}
else
DOpus.Output("XCopy result is not set.");
var cmd = DOpus.NewCommand;
cmd.SetType("msdos");
cmd.AddLine("xcopy.exe 1 2");
cmd.AddLine("/home/dopusrt.exe /acmd SetVariable Name=XCopyResult Value=%errorlevel%");
cmd.Run();
DOpus.Output("XCopy result (after): "+vars.Get("XCopyResult"));
}
Maybe there's another way to achieve what I thought of? May the vars collection could feature some "Update()" method?
Knowing that you're not willing to pimp the classic-button "scripting" anymore, being able to set DO variables externally would provide some glue between the "real" scripting and the classic way of doing things. I mean being able to just use {$file|noext} is way easier for anybody than fiddling with string operations or something. What do you think?
Notice:
The script button is going to fail on the last line on the first run, because the global variable [b]XCopyResult[/] is still missing. The following run of the button won't error, but it is going to show the value [b]XCopyResult[/] from the first run. Replacing %errorlevel% with a value of your choice makes this clear.
I think when using DOpus.vars, prefixing is not needed or possible at all, because this variable collection is meant to hold global variables only.
Besides that, setting the variable works good, it's just that the scripting environment does not know about it on time.
You got me thinking though, and I tried to replace the line which sets the global variable by dopusrt.exe and SetVariable with a @set-modifier, like so:
This works - kind of.. The running script can access "XCopyResult" right after being set, BUT@set does not resolve environment variables it seems, so the value of XCopyResult is "%errorlevel%" instead of "4". o) That was promising, but the goal is not reached by this, passing the returncode back to the DO script.
Using Wscript.Shell.Run() gives me returncode, but fails on resolving the control codes.
Using Command.Run() does not give me returncode, but will resolve the control codes.
Maybe I'm all wrong with this and there's a nice way to get both, then just let me know, thx! o)
@jon
My command invoked by dopusrt.exe is a custom script command, no way to run this directly/outside of dopus.
@idea-collector
What about a control-code evaluator, which I could use on the string to get codes working and then use this string for WScript.Run() to get returncodes?
@leo
"Rube Goldberg machine" - I liked that one! o))
Using %errorlevel% seems like a bad idea here. I'm not sure it is even set when running an exe like that, outside of a command prompt or DOS batch. (Even if it is, it won't be reliable if two things run in parallel.)
I would use Wscript.Shell.Run, and generate the command line using VBScript.
You can get all of the things you are using {} codes for easily using the Opus and VBScript objects. There is no need to depend on {} codes for any of it. The script objects let you do all the same things in script code (and if any things are missing, we can add them).
Sure this can be done, but look what beauty is in these codes! Fast and lean to use and there are month of work in them, so why not keep them at reach?
Yes, this is what I meant with "control-code evaluator". You gain a path, date-time, filename and what-else formatter instantly!o)
For advanced usage, you'd need an enumerator ontop though for this to support selected files e.g.
To sum up my findings:
@set or SetVariable update DOpus.var, but do not resolve %errorlevel%.
dopusrt.exe /cmd SetVariable does not update DOpus.var, but resolves %errorlevel%.
Anybody with some more tricks at hand to get %errorlevel% back into the script, while using control-codes? o)
Thanks @all for stopping by! o)
@jon
I misunderstood your idea at first, sorry! I instantly tried that of course.. o)