XYplorer Beta Club

Here's a scenario:

Let's say I have a file called abc.txt and it's located in C:\B\, but I don't know that it's there.

I navigate to C:\ and hit Ctrl+F. Type in *.txt (because I don't know the exact name of my text file either, just a rough idea) and leave the other options as default. Click Search and it finds a handful in C:\, including the one I want. Now I have a script I want to apply on this file. Here it is: As it turns out, the output of that script is written to C:\ and not C:\B\. While the former is technically correct from the point of view of being <curpath>, it's the latter that may be more desirable. In this case it is, I want to convert a file from one type to another, but for result of conversion to be in the same folder as source. Therefore, a native variable called <curitempath> (basically path to <curitem>) should be introduced so scripts can be applied to files paths of which are relative to files on which scripts are applied.

This is particularly useful when applying different scripts to individual files in search results window, especially since navigating to a folder where a particular file is, applying a script and clicking "Back" doesn't return you to the page with search results.

Unless they can be applied that way already without leaving the search results window, can they?

i usually do this and just in case the "2 fools rule" apply here, i also think <curitempath> would be useful.

Muroph wrote:i usually do this

Code: Select all

regexreplace $itempath, <curitem>, "^(.+)\\.+$", "$1";

and just in case the "2 fools rule" apply here, i also think <curitempath> would be useful.

Maybe a function getpath(item) would be even better? and getfile(item), and getextension(item)...

admin wrote:Maybe a function getpath(item) would be even better? and getfile(item), and getextension(item)...

I'm not so sure. Passing an item into a function is not extraordinary, but being a Java programmer I'm more used to methods being implemented as part of a class. So, your case it would be Item.getPath() etc. But I think we're making it more complex than it needs to be. There are native variables for just about anything already, expect for <curitempath> and I can only think of it being useful in a search results window (i.e. the only place in XY that you'd select a file that is in a folder but you're not in that folder), so that makes it a bit special.

The problem really is that the {Path} template variable for Report should probably return <curpath> for the Browse/Network/File modes instead of the text "{Path}".

TheQwerty wrote:

Code: Select all

Report("{Path}",1);

The problem really is that the {Path} template variable for Report should probably return <curpath> for the Browse/Network/File modes instead of the text "{Path}".

Yes, I see. I added a special field {fullpath}.

I added <curitempath>.

admin wrote:I added <curitempath>.

Thank you very much Don, it works great!