XYplorer Beta Club

I think there might be the need for another variable in scripting, one that might only be useful when used with PFA, but still one that - in such case - seems to me to be required.

I'm still not sure about what name would be best, so I'll stick with "pfa", simply. Maybe all the usual, so <pfaitem>, <pfaname>, <pfabase> and <pfaext>, or at the very least <pfaitem>

Those variables would relate to the item opened by the PFA. What I mean is this, say you have a PFA assigned for *.txt to a script, well then you simply cannot do anything, because <curitem> (or <focitem>) will always be the same one !

Come to think of it, the best would actually be an option to decide how the script will be executed : single, or multi- instance.

- Single: with use of <pfaitem> going through every selected item
- Multi: only triggered once even for multiple selections, and deal with <items> (and <item1> & <item2>)

I would think the easiest might be to say that one mode (single) is used with the standard prefix ( :: ) while the other (multi) comes with a "new" prefix ( ::: )



-----

Unrelated: there's still a bug with <curitem> -- Try this:
- go to a new folder, with at least one item
- make a selection using mouse only, no keys, and by drawing a rectangle from empty area (ie. no click on any item)
- ::msg <curitem> gets a blank/empty string, even with one item both selected & focused !

Uhm. Sorry for my lack of imagination, but I don't get it. Please give an examplethat shows the necessity of those new variables.

<curitem>: the current item is the one that's displayed in the statusbar and the info panel. This is mostly, but not always (as in your case), identical to the one focused and selected!

admin wrote:Uhm. Sorry for my lack of imagination, but I don't get it. Please give an examplethat shows the necessity of those new variables.

Well, any script that doesn't end using a command that relates to all selected items, but needs to deal with them individually. I'm not saying I know every possible use for this, but I feel I can think of a few...

- a script "::load <pfaitem>" to load the script, one might assume on 2 script files, you'd want each of them to be loaded, not the same one (twice)

- a script so that one dbl-click on files on a given location, they're not opened but copied to another location. That could work with copyto, but then requires that all files are on the same location and that the destination doesn't depend on the file name itself, but just its location

- a script that would "analyzes" the file path/name and add info related to that to the clipboard, creating a "template" for what needs to be done next

- a script that would allow you to dbl-click on a local file, its path/name would be "analyzed" and then another file would be opened. So you dbl-click on some local file, and automatically it's the file you want that's somewhere on the network that is being opened, or copied into current location and then opened...

That's what I can think of now, but I'm sure there are many more use for this, where you'd need the script to deal with items individually. In fact, I've even sometimes worked on script (not PFA related) where I have wished I had a way to go through each of the selected items one by one and do whatever it is I needed to do with them, because sometimes you can't just deal with all of them at once the same way (imagine a script that would rename each selected file, incrementing part of their filename. So that "foobar 14.txt" becomes "foobar 15.txt", or that doesn't rename the same way depending on the file's current name. Of course, the later would be better anyway when conditions & loops will be supported but...)

admin wrote:<curitem>: the current item is the one that's displayed in the statusbar and the info panel. This is mostly, but not always (as in your case), identical to the one focused and selected!

Yeah, well, that makes it weird because it would make sense to say current item = selected & focused, and most of the times that's what it is. Yet, sometimes, we have a file both selected & focused, but it's somehow not the current item. And some other times, we have no selection, yet there is a file as current item ! And I'm not sure there's a logic to it (I mean, one that can be (easily) understood and dealt with from a user POV)...

Okay, so thinking about it more, I changed my mind a little on this, and revised my wishes for scripting 2.0

I think it might be best to forget about all that (<pfaitem>), and instead give a script a way to go through each of the (selected) items on List one by one. That could apply to PFA but not be limited to it, and also useful for "regular" (non-PFA) scripts so that would be best I believe.

But the thing is, for such a thing we'd need loops, so it might be for scripting 2.0 - but after all v7 is out, so we can discuss this, right?

If we had <numitems> and <numselected> then it's a start, we can make the loop (with command dowhile or such), but we need access to an "array" of some sort. What might work I think might be something along the lines of this : So XY would have to give us a bunch of <item:N> and <selected:N> for example, so with that and <numselected> we could work our loop with <selected:$i> and then deal with each item as we please (Note that a support for $var{$i} or something equivalent for us as well might be nice).

With something like that, any script could deal with each of the (selected) files individually, and that would be pretty cool, for sure!

Okay, do me a favor and bump me later about this...

admin wrote:Okay, do me a favor and bump me later about this...

Don't worry I will, since that's on my own list of wishes