How do I set XY's default Script Path?

[Mesh]

I'm probably just blind, but I'm not seeing anywhere that I can set XY's default path for scripts.

I keep my scripts with my other data files - not only for the sake of organization, but also because I regularly nuke XY and replace it with a newer version. But right now, I have to repoint XY to my script folder every single time. If XY remembered the last Script folder used, this wouldn't be a problem, but because it doesn't, I'm trying to change the default path for scripts and apparently I'm too blind to find it.

Can someone tell me where I missed it?

[jacky]

Nope, you can't. As goes with everything else in XY and to ensure its best portability, the Script folder is "<xydata>\Scripts" ; that's the one used by command load first (or on UDC), the default place for "Scripting|Load Script File..." etc and it can't be changed (same goes for other folders in XY, e.g. NewItems)

[Mesh]

Nope, you can't. As goes with everything else in XY and to ensure its best portability, the Script folder is "<xydata>\Scripts" ; that's the one used by command load first (or on UDC), the default place for "Scripting|Load Script File..." etc and it can't be changed (same goes for other folders in XY, e.g. NewItems)

That's a shame - hopefully, that will be changed in the future.

[jacky]

That's a shame - hopefully, that will be changed in the future.

Why is it ? It's part of the way XY works : it is a portable app, and it keeps all of its settings and such in its data folder. Goes for Config, CKS, Catalog, New Items, Scripts, Search Templates, ... everything!

It makes sense, and it's not like you can't use script files from other places anyway, even from UDC, Catalog or anywhere you want. You could even have a script to list all Script files in a given location, and choose which one to load/execute...

[eurytos]

Unless I misunderstand him it is possible (or at least pretty close) to do what he wants.


In your installation folder there is a file named startup.ini. If you open it up you can set the path to the appdata folder. The appdata folder contains the \scripts\ and \newitems\ folders as well as all the .dat files and your xyplorer.ini

You can take the entire appdata folder out of the xyplorer install folder and put it wherever you want and then change the path in the startup.ini file to match. It isn't as flexible as specifying the script folder individually but it is close and it wont get messed with when you upgrade.

[Mesh]

Why is it ? It's part of the way XY works : it is a portable app, and it keeps all of its settings and such in its data folder. Goes for Config, CKS, Catalog, New Items, Scripts, Search Templates, ... everything!

It makes sense, and it's not like you can't use script files from other places anyway, even from UDC, Catalog or anywhere you want. You could even have a script to list all Script files in a given location, and choose which one to load/execute...

Oh, don't get me wrong - I have no problem with XY defaulting to that. But I think that XY should give users the choice rather than locking them in. Not everyone does things the same way.

Personally, I keep my code (C, VB, app scripts, etc...) all in one place. That makes it easy to organize, and easy to back up. I never put scripts in app directories - it's harder to keep track of, easy to forget to back up, and easy to lose during app uninstalls or data moves.

I regularly nuke my XY install when installing a new beta - it doesn't make sense to have to re-copy the scripts every time instead of just configuring XY to look in the right place. Especially given the other considerations listed above.


Even using XY as a portable app, I would still keep the scripts in a seperate folder on the portable drive - for all the reasons listed above. Allowing this to be configured doesn't handicap XY in any way - especially given its ability to parse portable paths. You can configure the script directory to be "?:\Source Code\XYplorer Scripts", and all is well. With that, you can delete the XY app directory in order to copy over a new one when you upgrade versions without worrying about losing anything vital.

[Mesh]

In your installation folder there is a file named startup.ini. If you open it up you can set the path to the appdata folder. The appdata folder contains the \scripts\ and \newitems\ folders as well as all the .dat files and your xyplorer.ini

You can take the entire appdata folder out of the xyplorer install folder and put it wherever you want and then change the path in the startup.ini file to match. It isn't as flexible as specifying the script folder individually but it is close and it wont get messed with when you upgrade.

I appreciate the suggestion, but that's a bit messy for my tastes. When I upgrade an app, I always do it cleanly - which means I delete all traces of the app before doing a clean install of the new version, and that includes config files. If I used this method, my upgrades would become a lot more complicated and unwieldy.

[eurytos]

Not sure if this is in scripting or not. But, if it is....


You could write a script that creates hard links to each of your scripts in your location of choice from the \scripts\ folder.

[jacky]

But I think that XY should give users the choice rather than locking them in. Not everyone does things the same way.

But what do you mean "locking them in" ? You can use script file from anywhere without problem, even from UDC, Catalog, other scripts, etc

If all you need is the Browse window to select a file and load it, you can just assign a KS (or Catalog item...) to this script :

Code: Select all

  inputfile $file, "D:\", "xys", "Select Script File To Load...";
  load $file;

Replacing "D:\" by whatever path you want, and you'll have the window in the folder of your choice!

I regularly nuke my XY install when installing a new beta

And why would you do that ? That's absolutely not required, plus it means you also loose all your config, Catalog, CKS, etc !! And if you do copy them elsewhere and copy them back after wards, then why not just include the "Scripts" subfolder in your script/process ?

With that, you can delete the XY app directory in order to copy over a new one when you upgrade versions without worrying about losing anything vital.

Well, I would most definitely put my configuration, Catalog, UDC, NewItems, CKS, etc under the vital category !!

[PeterH]

Do I understand you right: you will delete all files in appdata on a fresh install - that is .ini for all settings in XY, catalog.dat, findtemplates-Folder, etc., but you do not want to delete some scripts?
I think most users backup appdata with all it's subfolders, as there's much work in these files. And that's the reason why Don made location of appdata customizable - including the (default-)subfolder for scripts, but not scripts alone. You even can place appdata to user-specific files...

And if you backup complete appdata, you could restore only script-folder after delete & install, then all other files would be "resetted" state?

[Mesh]

But I think that XY should give users the choice rather than locking them in. Not everyone does things the same way.

But what do you mean "locking them in" ? You can use script file from anywhere without problem, even from UDC, Catalog, other scripts, etc

By "locking them in", I mean hardcoding the Scripts directory, rather than allowing it to be configurable.

If all you need is the Browse window to select a file and load it, you can just assign a KS (or Catalog item...) to this script :

Code: Select all

  inputfile $file, "D:\", "xys", "Select Script File To Load...";
  load $file;

Replacing "D:\" by whatever path you want, and you'll have the window in the folder of your choice!

Now *that's* a doable workaround! Thank you!

I regularly nuke my XY install when installing a new beta

And why would you do that ? That's absolutely not required, plus it means you also loose all your config, Catalog, CKS, etc !! And if you do copy them elsewhere and copy them back after wards, then why not just include the "Scripts" subfolder in your script/process ?

I've been in IT for many years, and I've seen no small number of problems caused by config files/registry entries that were either corrupted, or not quite compatible with a newer version. It's *always* better to upgrade cleanly. Problems are minimized by no small degree.

So, yes, I have to redo my config completely every time I upgrade XY - and I wouldn't have it any other way. It might make for a little more time and trouble along the way - but my systems go years (literally) without a single crash, freeze, or BSOD.

[Mesh]

Do I understand you right: you will delete all files in appdata on a fresh install - that is .ini for all settings in XY, catalog.dat, findtemplates-Folder, etc., but you do not want to delete some scripts?

When I update XY, I unzip the new build into an empty folder, delete the old XY app folder, and move the new app folder into it's proper location. Other than reconfig, that's it. Scripts are stored seperately, in their own folder, and I never have to touch them unless I'm updating them.

By integrating them with the appdata, I'm adding files and folders that don't belong there - to me, it's like people who save data files into the root of their C:\. In addition, I would then have to seek out all those unnecessary files and delete them - hoping that I don't make a mistake and delete some of the scripts by accident.

It's not a clean solution. However, Jacky's loader script is acceptable because it mimicks XY remembering a custom location for scripts, and allows me to keep my scripts folder free of files and directories that don't belong there.

[admin]

I've been in IT for many years, and I've seen no small number of problems caused by config files/registry entries that were either corrupted, or not quite compatible with a newer version. It's *always* better to upgrade cleanly. Problems are minimized by no small degree.

Well, my XYplorer.ini is 3062 days old! (You can check that value in INI under key dc (daycount)).
At least you probably know your license key by heart now...

[jacky]

Well, glad I could help

Back in here because this reminded me of something I've actually been meaning to wish for a little while now : a new XY variable like <xyspath> that would be:
- <xydata> for internal scripts
- the location of the current script file otherwise

The later being the whole point, obviously, because that place can be used automatically by commands like load or getkey, but there's no way of knowing what it actually is. So when for example I want my script to remove the INI file it created, for some reason, I either have to force a strict path when using it, or assume it's under subfolder Scripts which, while mostly true for me, isn't the best thing to do.

[Mesh]

Well, my XYplorer.ini is 3062 days old! (You can check that value in INI under key dc (daycount)).
At least you probably know your license key by heart now...

Oh, don't get me wrong - it *can* work to leave everything in place, but I've seen it cause problems so often that it's just not worth it, in my opinion.

It's less of an issue with smaller programs like XY (although it definitely does happen) - but apps with more complex configurations, such as Adobe products, or - God forbid - when someone decides to upgrade their O/S (e.g. installing XP on top of W2K), is just begging for there to be major issues right from the start.