Sorry this is quite a brain-dump. 
The problem I foresee with using PVs in this way is they are not read-only. Remember PVs don't need to be brought into the local scope so my script might use a local variable
$st which is going to break your configuration until you restore the value. Adding read-only PVs could also get confusing and problematic if they just look like normal variables.
I view aliases as more of "triggers" rather than variables - they perform scripts or gotos via names - so to me at least they aren't a natural fit. I also think something like this is imperative to the wish, but aliases cannot handle it today:
Code: Select all
@apps=C:\Program Files
@xy=XYplorer
@xyexe=<xyexe>
@runAwesome=@apps\@xy\@xyexe
(I realize this view is not shared by everyone - but it should be.
)
There are however two partial solutions today.
I don't feel either is quite where they need to be to work very well, but it might not take much for Don to get them there.
1) Use environment variables
They are perfect for this and available even outside of XY, but they are not so easily portable.
You'd have to either:
-Change the Windows session environment.
-Start XY with a prepared environment (could be done via batch file).
-Have Don modify the environment using values in
Admin.ini or a new
Env.ini.
-Have Don provide scripting commands that can modify the environment.
Any of these should also make the variables available within programs you run from XY, like the command prompt.
2) Use the existing /user command line switch
Start XY using
XYplorer.exe /user="E:\Utilities\Sublime Text\x%osbitness%\sublime_text.exe|E:\Utilities\JGsoft\EditPad Pro\EditPadPro7.exe"
Then you could access them via index using
<get CmdLineUser 1> for
%st%, for instance.
That kind of sucks though since we want many variables, with possibly long values, and would prefer meaningful names to counting out indexes.
Maybe Don could have
/user accept an INI file or automatically read in any
User.ini files it finds in
<xydata> and/or
<xypath>. Even better would be to expose the file in List Management, its path in
<xyuserini>, and to have a command
Reload User Variables (for use with
SetKey SC).
That improves the defining of the values but
<get CmdLineUser ...> is still cumbersome. I think two alternatives
<userVar ...> and the shorter still
<uv ...> would be much better.
Now we wait...
EDIT: 2015-02-09: Split off the discussion on
Modifying XY's Environment.