XYplorer Beta Club

ivan wrote:I am also wondering if it would be possible to implement an option to override Windows so it doesn't display the pop-up asking if i want to move to bin or if i want to permanently delete...

Configuration - Advanced : Turn off delete confirmation

Thank you! However, I'm thinking that something like this would not always be applicable i.e you may only want to delete without confirmation window only when you run a particular script, like I do in this case. In all other circumstances I'd rather the box did pop up. Would I be right in assuming that if an option is available to be set in Config menu then it's possible to call it in a script, right?

EDIT:

The impression I'm getting is that a script's purpose is to carry out a specified precise action, whether it's on a small or large scale. As such, XYplorer should have a setting, probably in the same Config -> Advanced, that would say something like "Allow scripts to override settings". Or maybe have it in UDC menu so it can be applied on a script-by-script basis. In my opinion, using an option of turning off deletion confirmation as a workaround for one script is like trying to kill a fly with a nuclear bomb

ivan wrote:I am also wondering if it would be possible to implement an option to override Windows so it doesn't display the pop-up asking if i want to move to bin or if i want to permanently delete...

Sure: use #1054; (Nuke) instead of #169;

and would #1055 be the equivalent of #170?

Oh, I edited your post instead of replying to it...

You could replace #169 in the script with an OpenWith() command that makes use of the del system command.

You could globally turn off the confirmations.
Remove Del as a CKS for #169.
Create a UDC: "::Msg("Delete for serious?", 1);#169;"
Assign Del as a CKS for that UDC.
Then anywhere you want the prompt use the UDC, and no prompts use #169.

Or perhaps Don could add a new valid value to the Setting() command.


Just a few workarounds.

I'll wait until Don implements #1055, but judging by the logic of that table I'm surprised it hasn't been integrated already

you know that IMHO the one thing Don should add, for this and other uses, is simply a new command delete :
delete [<items>][, <bin>][, <confirm>][, <skip>]

All params optional:
<items>: ;-separated list of items to delete, instead of selected List items
<bin>: 0=direct delete, 1=recycle bin (default)
<confirm>: 0=no confirm, 1=confirm (default depends on user setting)
<skip>: 0=no skip (default), 1=skip locked

jacky wrote:you know that IMHO the one thing Don should add, for this and other uses, is simply a new command delete :
delete [<items>][, <bin>][, <confirm>][, <skip>]

All params optional:
<items>: ;-separated list of items to delete, instead of selected List items
<bin>: 0=direct delete, 1=recycle bin (default)
<confirm>: 0=no confirm, 1=confirm (default depends on user setting)
<skip>: 0=no skip (default), 1=skip locked

As long as each of 6 possible combos is accessible via a numbered command then I'm cool with it, but the majority is already possible and #1055 should add icing to the cake

jacky wrote:you know that IMHO the one thing Don should add, for this and other uses, is simply a new command delete :
delete [<items>][, <bin>][, <confirm>][, <skip>]

All params optional:
<items>: ;-separated list of items to delete, instead of selected List items
<bin>: 0=direct delete, 1=recycle bin (default)
<confirm>: 0=no confirm, 1=confirm (default depends on user setting)
<skip>: 0=no skip (default), 1=skip locked

HA! Just came back from doing it, that's synchronicity!

I opted for a slightly smaller version for now, more later...

This When implemented in a script, needs to override any setting a user may have set for the reasons I already mentioned. This means that if this is called in a script then no pop-up box should appear even of the box in Config -> Advanced is unticked.

admin wrote:HA! Just came back from doing it, that's synchronicity!

hehe... yes, I know my XY

ivan wrote:When implemented in a script, needs to override any setting a user may have set for the reasons I already mentioned.

Yeah that's kinda the whole point ! When unspecified it default to the user option, but the script author can force to show a confirmation (1) or not (0)...

jacky wrote:Yeah that's kinda the whole point ! When unspecified it default to the user option, but the script author can force to show a confirmation (1) or not (0)...

I was just making sure. Clearly, having it set to [1] and having the box ticked in Advanced can result in a clash as can having it set to [0] and box unticked. It's important to make sure the privileges are sorted out

admin wrote:

jacky wrote:you know that IMHO the one thing Don should add, for this and other uses, is simply a new command delete :
delete [<items>][, <bin>][, <confirm>][, <skip>]

All params optional:
<items>: ;-separated list of items to delete, instead of selected List items
<bin>: 0=direct delete, 1=recycle bin (default)
<confirm>: 0=no confirm, 1=confirm (default depends on user setting)
<skip>: 0=no skip (default), 1=skip locked

HA! Just came back from doing it, that's synchronicity!

I opted for a slightly smaller version for now, more later...

Well, I have to say I do like my implementation (or, you know, the idea of it, since that's where I stop ) better. Main reasons :

- the Tree/List thing sounds a bit odd to me, and not required : couldn't one just have done a "::focus Tree; delete;" to do the same, and force deletion of the Tree's selected item ?

- Maybe there's some internal complexity I don't know about, but I think a ;-separated list of items to delete would have been good/useful I feel, and since other commands support such a thing it seems consistent to offer it here as well...

- I really don't like that the default isn't the User default. Not that it clashes with my own config, it actually doesn't, but if a user asks for no confirm, why should a script go against his will/options, unless the script (author) specifically asks for it ?? I think default should be whatever the option says...

I was really going to post the same thing as jacky yesterday but thought I'd let it sink in first. And after all that sinking, I still agree.

jacky's command seemed to be more consistent with all the existing commands.

Merging the modes together isn't a bad idea, but I think it's more clear if they are separate parameters.

I expected this, but much earlier!
I agree that it can be improved. Wait...