Various Script Wishes

[jacky]

Was working on a few scripts today, and so I have a few wishes to add to the list

- there's already been an idea of "global" variables (over sub/load/etc) that has been mentioned already, so let me just say "+1"

- I'd like a couple of new commands: newtab & closetab
No need to explain what they do I think, and it'd be nice if newtab could receive a parameter <location> (instead of having to do "newtab; goto <location>;") That'd be really cool, cause for a few scripts I do need to use the GUI (List, select files, etc) and I feel it's better to open a new tab, do my stuff, and close it (or else location, sort order, selection, etc are all screwed)

- I think another command that'd be nice is: del <pattern>[, nb][, s]
<pattern> : full path to a file/folder to delete. Maybe accept pattern (eg: d:\*.txt) ?
nb: no bin
s: silent, i.e. no confirmation

- how about a new param for try: <script> (empty: last used in session, otherwise put up the given script)

- open/openwith : could it be possible for those commands to wait until execution is over ? So I can start a compress job, and only execute what comes next once done...

[TheQwerty]

I aggree with all those except this:

- open/openwith : could it be possible for those commands to wait until execution is over ? So I can start a compress job, and only execute what comes next once done...

I see your point but why change these commands when you could just follow them with a Msg();?

Yes it means there needs to be user interaction to proceed in the script but I think that's needed here either way, as it's not a good idea to just assume the opened file/program completed successfully.

----------

As for the tab commands, I almost posted the exact same thing. I'd also like to see RenameTab([Name]);

[admin]

FYI: No more new features until 7.0 is out. Currently writing the documentation plus major restructuring of website. May take a while...

[jacky]

I aggree with all those except this:

- open/openwith : could it be possible for those commands to wait until execution is over ? So I can start a compress job, and only execute what comes next once done...

I see your point but why change these commands when you could just follow them with a Msg();?

Well, for starter I didn't really say it, true, but in my mind that would of course have been as an optional parameter; and yes I do use an msg right after for now, but it just seemed like it would be better done that way.
Besides, what if the application started was to not have any GUI but only process data (eg like compress files, but without a window showing progress), then the user would have no way to tell whether or not it's finished, while XY could.

FYI: No more new features until 7.0 is out. Currently writing the documentation plus major restructuring of website. May take a while...

No worries, I kinda sense that you were working on the upcoming v7 and not willing to add anything/open any can of worms for now...

[TheQwerty]

Well, for starter I didn't really say it, true, but in my mind that would of course have been as an optional parameter; and yes I do use an msg right after for now, but it just seemed like it would be better done that way.
Besides, what if the application started was to not have any GUI but only process data (eg like compress files, but without a window showing progress), then the user would have no way to tell whether or not it's finished, while XY could.

And in that same instance what if the application fails?

I'm not sure, is it possible for XY to handle this reliably when the commands are used to open a file using the handler defined by the Windows associations?

Also, how should this waiting/blocking state be presented to the user? Would a custom dialog which is displayed while XY is waiting and automatically closes, work well? Perhaps it should be something like:
"Waiting for ... to finish.

Press OK to stop waiting and proceed.
Press Cancel to stop the script."


Just to be clear, I don't object to the idea and the need for something like this, at least assuming this is an optional parameter or additional command and not the default. I'm just playing a bit of devil's advocate.

[jacky]

Yeah, no, clearly you're against me, I can see that.

And in that same instance what if the application fails?

Well, that's for later, when we'll have conditions. Then, the function would just wait & set into a variable the result (error code); then the script deals with it accordingly...
Meanwhile, we have no way to tell, that's truth. Same goes right now when we assume a "open(with)" will do fine and move on to other script commands though... As you said, there's always the possibility to add an input to prompt user.

Also, how should this waiting/blocking state be presented to the user? Would a custom dialog which is displayed while XY is waiting and automatically closes, work well?

What I had envisoned was simply a hourglass mousepointer, and a statusbar that'd read "Waiting for the end of XXX's execution..." or something, which seemed more "XY" to me (same way as done during File Find, Backups, etc) - with possibility of using ESC to stop the wait, and the script execution.

[jacky]

Adding on the list for post-v7

- a new command "confirm" : just an msgbox like the msg command now, but with a Yes/No choice : Yes means continue script execution, No means abort
Right now I'm using input to do that, but it just doesn't look as good

[admin]

Adding on the list for post-v7

- a new command "confirm" : just an msgbox like the msg command now, but with a Yes/No choice : Yes means continue script execution, No means abort
Right now I'm using input to do that, but it just doesn't look as good

Already on my list.

[jacky]

Already on my list.

Doesn't surprise me

[graham]

Can I ask if the toolbar button for scripting be change colour from blue to red when not stepping as a visual warning. The dpressed button icon is not that easily seen.

[admin]

Can I ask if the toolbar button for scripting be change colour from blue to red when not stepping as a visual warning. The dpressed button icon is not that easily seen.

I understand, but it is not possible right now easily. I would have to add that sort of functionality (different icon when pressed) to the toolbar.

[graham]

admin wrote:

I understand, but it is not possible right now easily. I would have to add that sort of functionality (different icon when pressed) to the toolbar.

Yes, I can see that is a problem. Because of the need to be assured that stepping is off can I suggest as an alternative approach

In the status line where you report scripting progress in red it shows 'Scripting without stepping!' when the tool button is pressed.

I realize this may seem a trivial request but it can be catastrophic if one runs a script thinking it would step and it doesn't. I take extra care to check but....

[jacky]

Might not apply here, but when you write new scripts and want to check how things go, just always use "step" as your very first command. Then, you'll be stepping no matter what the button says...

[graham]

Playing around with a few scripts and I keep finding the need for the msg command to allow an escape as well as OK

Or another command to do this ?

reason - if a script is started I usually head it with a msg showing the script title and if by mistake I started the wrong script it would be good at this stage to escape from the script. Not this applies when not running in step mode.

Or a command to branch to a label in the script - that offers a massive power step to combine script options.

[jacky]

Yeah, as said above it's not possible yet, but you can use input instead for the moment :
input $void, "Shall we continue ?", "Press CANCEL to abort script";