User defined variables

[mkolaski]

Does XYplorer offer a facility to set up user defined variables?

For instance, in FARR, I can define a directory path as a user defined variable:

2015-01-24_12-47-49.png

This can then be used to set up an alias:

2015-01-24_12-29-29.png

I can then just copy my config file to another PC and change the main directory path where all my portable apps are kept on that PC.

If it's not available, I think it would be a useful addition as, if XYplorer is used on different machines, it's likely to be installed in different drive or directory locations and this would mean that, rather than using hard-coded or relative paths to external apps (which are likely to be different on each machine), they could all be set in one place making script/UDC/catlog maintenance much easier when using multiple machines.

Cheers,
Michael

[bdeshi]

There are Native Variables such as <xypath> which is the folder where XYplorer.exe resides.
Using these, you can locate other file/folders in a relative location (eg, <xypath>\..\parent). Also, ?:\ equals the drive where XY lives.
Enter the underlined code in the addressbar for a list of such variables (not all are path-related!): ::help "idh_variables.htm";

In the scripting context, in addition to natives, there are also permanent variables (perm $APermanentVariable = "some value";) and are available to all scripts.

But permanent variables cannot be used anywhere outside of scripting, for say, defining ctb icons, catalog entries, (non-scripted) file associations etc, and native variables cannot be arbitrarily user-generated.
(unless they're declared in the XYplorer command argument and retrieved with <get CmdLine [index]>, which is a clunky method at best, with numerous disadvantages.)


That said, there is one thing: Aliases, that could come handy but is sadly often ignored. [del]
==Intermission==
Aliases are a revolutionary feature! It demands some love!
==Intermission==

Aliases are supposed to be a shorthand of sorts for locations, so it sounds logical that they be useable alongside and everywhere as native variables.

[bdeshi]

[Wow, this was a reveal-ation!]

You can actually use aliases everywhere, using <get alias aliasname>!

@st=<xypath>\..\SublimeText\sublime_text.exe
CFI: ini><get alias st>
PFA: ini><get alias st>


=======
edit:

So to answer your question: yes XYplorer has superb support for user-defined variables.

Enter the following in the addressbar to setup an alias called myVar:

Code: Select all

@PortableAppsDirectory=D:\Dropbox\Apps

Now you can directly enter @PortableAppsDirectory in the addressbar to go there.
And this string can be re-used almost anywhere native variables are allowed in the form of <get alias PortableAppsDirectory>.
[Note: use <get alias PortableAppsDirectory>\XYplorer\ as a way to navigate to locations relative to the assigned location]

Although this is not still allowed in ctb icons, captions of tab, catalogs,ctbs etc.

I recommend you read what the manual has to say about aliases: ::help "idh_addressbar.htm#idh_alias";

[Stef123]

A heavy user of aliases I've been wanting to ask this for a long time: Do I pay a performance penalty for piling up tons of aliases in my PFAs and favorite F&F and other CTBs? Because XY has to resolve the alias first, then take it from there, to build up the remaining path components.

I can't really test it, this would mean I'd have to replace a lot of paths.
Could it mean XY takes longer to launch because it first gathers all my aliases on start-up?

[admin]

No notable penalty. Can only be nanoseconds.

[Stef123]

Relieved to hear that. Thanks.

[mkolaski]

Thanks for your help, Sammay, that's perfect.

I spent some time reading the help manual when I first started using XYplorer and have been using some of the native variables and I remember reading about aliases and thinking they were just a quick way to navigate to folder locations (and I can either use the catalog or FARR for this) so I sort of dismissed them, but they're just what I want (being clearer than relative paths and meaning that I only have to change one item if I install XY on a new machine) as I can either use them in scripts when defining paths to external apps as well as in catalog items. I have one set up to open FileLocator Pro to search the folder location in the active pane and it works perfectly when using this:

Code: Select all

"<get alias PortableAppsDirectory>\FileLocator Pro\FileLocatorPro.exe" -d "<curpath>"

Thanks again.

Cheers,
Michael

[binocular222]

You can actually use aliases everywhere, using <get alias aliasname>!

@st=<xypath>\..\SublimeText\sublime_text.exe
CFI: ini><get alias st>
PFA: ini><get alias st>

This example almost convince me that alias is worth using. However, alias does not resolve variable turn me off, such as:
@nircmd=<xyscripts>\nircmd\x%osbitness%\nircmd.exe

[bdeshi]

@nircmd=<xyscripts>\nircmd\x%osbitness%\nircmd.exe

it seems to works all right here?
normally these goto and select the target exe.

Code: Select all

@test=<xypath>\..\Notepad2x%osbitness%\notepad2.exe
@nircmd=<xyscripts>\nircmd\x%osbitness%\nircmd.exe

in CFI, although they're shown as the dreaded ! alert in the cfi list, the associated icon is displayed correctly in the browser.

Code: Select all

txt><get alias test>
dat><get alias nircmd>

<ed>

[bdeshi]

Oh, they're not resolved in PFAs... Don?

[binocular222]

Not resolved in scripting too (the most painful to me):
@nircmd=<xyscripts>\nircmd\x%osbitness%\nircmd.exe
::echo get("alias", "nircmd")

I think variables inside alias should be resolved everywhere so that alias can be a "pool of paths" that can be resued by PFA, CFI, SC,...

[TheQwerty]

Not resolved in scripting too (the most painful to me):
@nircmd=<xyscripts>\nircmd\x%osbitness%\nircmd.exe
::echo get("alias", "nircmd")

This can be solved by using the reprocess flag of the set SC:

Code: Select all

set $aliasValue, get('alias', 'nircmd'), 'r';
echo $aliasValue;

It also works when using $aliasValue = get('alias', 'nircmd'), 'r'; but this is so ugly and potentially misleading that it should be avoided at all costs.

Part of the problem with having XY always resolve them everywhere is that the value can actually be a script and it might not be desirable then.

Code: Select all

@exeModifiedDate=::sel '[*.exe]', 1, 1;echo "<datem yyyy-mm-dd>";

If XY resolves variables first the date var will be replaced with the value for the current item and thus won't use the value of the item selected by the script.


My thoughts are that the Alias info value for the get SC should make use of param2 to specify whether or not the alias value should be resolved/reprocessed. Thus your original example could be:

Code: Select all

// Given: @nircmd=<xyscripts>\nircmd\x%osbitness%\nircmd.exe
::echo get("alias", "nircmd", 'r')
// or
:: echo <get alias nircmd r>;

This would then make the resolved value available in places where variables but not scripts are possible.

[binocular222]

I might missed something, but how to set alias via scripting?

[bdeshi]

Code: Select all

 goto "@echo=::echo <@1>;";
 goto "@echo2=""::echo <@1>;""";
 goto '@echo3=::echo "<xypath>";';

Code: Select all

@echo Hello!
@echo2 Hello!
@echo3

huh, here's one for myself

[binocular222]

you do have lots of dirty tricks!