Let's be modest, here are some mind-blowing ideas!

[TheQwerty]

Okay, since you are a bit more into scripting than me: How would you integrate this into the syntax? Add a parameter "wait" to open/openwith/run, and when wait==1 then only continue when the process has terminated?

Yep, exactly. Well, except that as I said, the way I envisioned it there would be a little window while XY is waiting (to clearly indicate one cannot continue using XY, start other scripts, etc - Plus abort the wait/script execution), and it might be nice if the script could add at least one line in there, to describe what's going on.
So either add another param <msg> for that text, or make it that the new param must be !="" to trigger the wait, and then it is the message shown on the "waiting window" (which, I guess, doesn't prevent to say if ==1 then the message default to a simple "Please wait...").

I'd strongly recommend adding a RunWait function instead.
It would have the same syntax as the Run command, but would add an additional parameter for the message to show while waiting.

The reason I suggest a function instead of a command is because it could then return the application's return code easily, which would be useful.

[admin]

In my very limited exposure to scripting I found that on occasion simple script commands like file deletion could take varying times to complete and any following XY script line needed to be aware of this if it then assumed the delete happened.

AFAIK (AISK*), delete does not return until it is finished.

* AISK = and I should know

[PeterH]

Shouldn't the default for every command be to "wait for completion"? Thinking about programming experience I don't remember I've seen anything else.

As an example: a file-read is always synchronous (data can be used immediate after the read-operation) - unless I specify it as "Unsynch", but then I have to "wait for completion" before using the read buffer.

For me it's so that I "automatically" expect, that when a command is executed, the previous command has finished. And I think, just this is the secure sequence. If it's not, it must be accounted for by the script - and in that case can be requested as "async" in the command.

And sure there is a reason (for some commands) to allow asynch usage - but then you often need the ability to wait for completion...
As, if I delete/copy/move/rename/... 1000 files, or whatever, the next operation always could be dependent from that previous operation. Only I can know if it's not, and only I can decide, if and when a later "wait for completion" could be neccessary.

[jacky]

Shouldn't the default for every command be to "wait for completion"?

Well, apart from the command we're talking about here, that launched an app and then continued, I do believe all other commands to wait for completion. I didn't check or anything, but I'm fairly sure delete, backupto, moveto, etc do wait for completion before moving on.
Launching an app was a special case, and so commands open/openwith and run I think might have been the only ones in this situation.

I'd strongly recommend adding a RunWait function instead.

Yes, if we want to have return codes of course a function would be better, but I don't know if that's doable as easily. Which is why I said that, I felt, if it could be done even without rc, it should.
(I imagine <wait> could also, if a variable, be set to the return code. Of course, a function would still be better.)

--

About the latest beta, pretty cool! Seems to work fine, but I have to ask about the lack of "waiting window" but allowing one to continue using XY, is this really a good idea ??

For one, user can't abort anything, if somehow something goes wrong XY could maybe end up waiting for something endlessly?

Also, it could allow for many scripts to run at once, and I'm not sure what this could possibly mean, but it sounds bad.

Not to forget, it might be "dangerous" as one script starts an app (e.g. extracting an archive), but in the mean time user might change the current location and whatnot, and then when the script execution continues, it assume it's in the same folder or that settings are still as they should be (cause "setting" was used before launching the app), only meanwhile the user noticed his settings were changed and changed them back manually. So we're saying that after a run&wait, you gotta assume nothing, location might have changed, settings (even set with setting before) might have changed as well, Hell even global vars might have changed from right before you launched the app!!
Because, yes, while the user might (feel like) he can continue to use XY as if the script was done, the thing is his settings might have been changed (since a script is still running), which could lead to unexpected results.

No, I do not like that so much, I have to say. I see no reason not to use a "blocking" waiting window (and at the very leats I'd like an option to use one, if you don't want to "force" it on...). The script needs to wait for execution to be over to continue his work, so one must wait -- hence the window. If you just want to start an app and do something else, don't use the <wait> option! No?

[admin]

Easy, easy, I agree about the "blocking" waiting window -- I just needed another moment to meditate about the best implementation. It's a bit tricky to do (because a modal window will stop code execution) but I think I found a way...

[graham]

graham wrote:
In my very limited exposure to scripting I found that on occasion simple script commands like file deletion could take varying times to complete and any following XY script line needed to be aware of this if it then assumed the delete happened.

Done replied:

AFAIK (AISK*), delete does not return until it is finished.

* AISK = and I should know[/

quote]

Very glad you know these things. At the time I was convinced my then script failed because the delete but it must have been a combination of a previous run command that had not completed and caused my problem.

Live and learn - looking back there was a prior run command so this must have been the culprit - at least this simplifies the problem for me if not for you!

[jacky]

Easy, easy, I agree about the "blocking" waiting window -- I just needed another moment to meditate about the best implementation. It's a bit tricky to do (because a modal window will stop code execution) but I think I found a way...

Looking good!

[jacky]

Question: is "run" gonna be the only command to support this ? Because for a script of mine I can't use it, as it seems the current/working folder set when using it is <xypath> (I guess, might be <xydata> they're the same for me, but the first makes more sense I think) and not the app's path.

Unfortunately, the app I need to use is looking in its "current" folder for some of its data/config's files and folders, obviously can't find them (in <xypath>) and therefore refuses to work

This doesn't occur when using "open", so I assume it sets the current/working dir to the app's path. So: will "open" also support this wait parameter ? And if not, could there be a way (extra param?) to set what the working dir should be when using "run" ?

[admin]

And if not, could there be a way (extra param?) to set what the working dir should be when using "run" ?

Yep, I will add a param to run.

[admin]

And if not, could there be a way (extra param?) to set what the working dir should be when using "run" ?

Yep, I will add a param to run.

Question: what's your command line, jacky? Because I have a mechanism that auto-determines the working dir. Only it does not seem to work with each command line.

[jacky]

Question: what's your command line, jacky? Because I have a mechanism that auto-determines the working dir. Only it does not seem to work with each command line.

Sorry for the delay, got busy with silly Windows problems today. Anyways, the one in question goes like this:

Code: Select all

open """$root\AutoMKV095\AutoMKV095.exe"" automkv.ini ""$folder\$file"" 0 0 0 0 start kill";

[admin]

Question: what's your command line, jacky? Because I have a mechanism that auto-determines the working dir. Only it does not seem to work with each command line.

Sorry for the delay, got busy with silly Windows problems today. Anyways, the one in question goes like this:

Code: Select all

open """$root\AutoMKV095\AutoMKV095.exe"" automkv.ini ""$folder\$file"" 0 0 0 0 start kill";

Okay, and what would be the desired working dir? Where should I attempt to extract it?

... well, this question is actually kind of outdated, since with the last version I decided to either pass the working dir explicitly or default it to current dir. Does this work for you?

[jacky]

Okay, and what would be the desired working dir? Where should I attempt to extract it?

... well, this question is actually kind of outdated, since with the last version I decided to either pass the working dir explicitly or default it to current dir. Does this work for you?

The working dir would have been "$root\AutoMKV095\" and a quick test seems to indicate that it does work fine with the latest beta indeed, yes, thanks a bunch!

PS: Horrible horrible bug: on the post for that latest beta, you said "7.90.0025" instead of 0024 (as indicated on changelog) ! Doesn't look like much, but it gets my XYAU a little confused, thinking it's the wrong version and all...

[admin]

PS: Horrible horrible bug: on the post for that latest beta, you said "7.90.0025" instead of 0024 (as indicated on changelog) ! Doesn't look like much, but it gets my XYAU a little confused, thinking it's the wrong version and all...

Oh la la! Hot-fixed!

[jacky]

Oh la la! Hot-fixed!

Thanks, now I can breathe again!