Date info in status bar

[jacky]

I'd say keeping a custom settings file with the script that uses it is very likely to be "standard" script use, whatever that is.

You are free to assume all you want, but if I've learned anything in my time as a programmer it's to never assume anything. A certain saying comes to mind...

Well, keeping settings with the script file sounds pretty "standard" alright, but such scripts should be within <xydata>\Scripts anyways, as it is the officially recommended thing to do.

I know assuming what people will do is "wrong", but in this case it's not so much assuming as recommending : XY is a portable app, not just because it comes with no install and uses an INI file, the entire app has been thought that way (see PFA, relative syntax, etc) and wile not enforced (as for XY's own INI files), it is highly recommended to store all your script files within <xydata>\Scripts (in fact, "load foobar" will look for <xydata>\Scripts\foobar.xys), and so it is only logical to recommend to store any additional settings within <xydata> (or <xydata>\Scripts if you prefer) as well.

[TheQwerty]

While the majority of my scripts are in <xydata>\Scripts, most of them are in sub-directories of that. And then I have some scripts that I prefer to keep with the project that they are used to manage.

So in both cases if I want to have a custom INI file with my scripts, I have to hard-code the path information, which means if I ever change the paths, I have to go back and update all the scripts.

Quite frankly, it would have made much more sense to define the starting point for relative paths differently depending on how the call is made. If Get/Set-key is called from a UDC or Quick Script it should be relative to <xydata>. However, if it is called from within a script file it should be relative to the script file itself.

As it is, since we already have <xydata> and <xypath>, there is very little gained by having either be the start.

[jacky]

Well, for the record I was never opposed to a <scriptpath> variable or something like that, although comes the question of what to do when the script doesn't come from a file (simple answer being simply use <xydata>). Because at least when sharing scripts, you never know what the end user will do, keep it in a file, or not.

About your examples, at least for the ones in subfolders, that's no problem, you can use <xydata>\Scripts\Subfolder\filename.ini
Of course, part of the path is still hardcoded, but at least not all.

Now, after reading your post & thinking about it more, I think I'm changing my mind though : it would make more sense to use the relative syntax from the script file's location (when not a file, use <xydata> as it is, in a way, the script location - through udc.dat, catalog.dat or whatever)

Because as you say, it's easier for the script author not to care and to know the INI will always be with the script, one can always head back to use <xydata> to put it there, and since command load already uses that location as starting point when loading another script file, it only makes things consistent that getkey/setkey would do the same for what may be the script's settings.

But of course there's the idea that, at first, those commands were to deal with XY's INI files, which have to be located in <xydata> - that's a requirement, not a choice.
And in that case, to have to leave blank for the current INI, or to use another (XY's) INI to be required to prefix with <xydata>\ to be sure, in case the script file is elsewhere, might look "odd".

Although, everything still is logical, and given how it allows for more possibilities putting the relative syntax inside the script's location, I'd say if possible this should be changed after all, I agree with you.

[admin]

But of course there's the idea that, at first, those commands were to deal with XY's INI files, which have to be located in <xydata> - that's a requirement, not a choice.
And in that case, to have to leave blank for the current INI, or to use another (XY's) INI to be required to prefix with <xydata>\ to be sure, in case the script file is elsewhere, might look "odd".

Although, everything still is logical, and given how it allows for more possibilities putting the relative syntax inside the script's location, I'd say if possible this should be changed after all, I agree with you.

Just to make sure; these are the changes you agreed upon (And I like them, too):

if no INI file is stated: the current app INI file is used (as is now)
if no (or relative??) path is stated: it is resolved to the current script's path (NEW!)
it absolute path: well, absolute path. (as is now)

Logically, <xydata>\file.ini would be needed if file.ini is configuration file for XY, but not the current one.

EDIT: done.

[jacky]

Just to make sure; these are the changes you agreed upon (And I like them, too):

if no INI file is stated: the current app INI file is used (as is now)
if no (or relative??) path is stated: it is resolved to the current script's path (NEW!)
it absolute path: well, absolute path. (as is now)

Logically, <xydata>\file.ini would be needed if file.ini is configuration file for XY, but not the current one.

EDIT: done.

Yes, that's exactly it! Well done (as always), and I'm sure TheQwerty will like that as well!

[TheQwerty]

I'm sure TheQwerty will like that as well!

Indeed, that will work perfectly! Thanks Don!