How do I set XY's default Script Path?

[admin]

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.

Well, in XY it's supposed to work and it does work. And even if you erase everything, upgrading itself is risky, of course, because who knows what you will get? Hey, everything is risky, isn't it. Okay, you reduce the risks where you can, but loosing my configuration for each upgrade? That price is too high for me.

[TheQwerty]

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.

Yep, I still think this is needed, but I'd prefer if it were called <scriptpath>. <xyspath> is just a little too similar to <xypath>, which make debugging difficult, and could cause problems if the user accidentally drops the s.

[Mesh]

Well, in XY it's supposed to work and it does work. And even if you erase everything, upgrading itself is risky, of course, because who knows what you will get? Hey, everything is risky, isn't it. Okay, you reduce the risks where you can, but loosing my configuration for each upgrade? That price is too high for me.

Completely understandable. To each his own.

[graham]

Well, in XY it's supposed to work and it does work. And even if you erase everything, upgrading itself is risky, of course, because who knows what you will get? Hey, everything is risky, isn't it. Okay, you reduce the risks where you can, but loosing my configuration for each upgrade? That price is too high for me.

Completely understandable. To each his own.

I have some sympathy with your experience of risk but this, I have found from experience, is mainly due to shared folders or places storing mixed data - the registry is a major source of corruption and holds many entries that are useless or plain wrong (reason for good program to clean it - rec. ACE Utilities). In the case of XY it is all nicely self contained and only corrupted by the user messing around or a bad issue which i have yet to see.

For my peace of mind, I update XY using a script that backs up the key data files with 5 backups in total and automatically downloads and installs the newest version - great use of a script and bat file plus Jackies regx advice. All this takes one single click of the mouse and I have the latest version up and running and the previous version stored and 4 more if needed - surely this is as easy as it can get and has security if things were screwed by some mishap.

So glad XY is not using the registery - just like old times!

[Mesh]

I have some sympathy with your experience of risk but this, I have found from experience, is mainly due to shared folders or places storing mixed data - the registry is a major source of corruption and holds many entries that are useless or plain wrong (reason for good program to clean it - rec. ACE Utilities).

While that's certainly a contributing factor, this problem shows itself with self contained config files as well. One scenario (of many) is that it's common that older entries are preserved through an upgrade, even though they may no longer be supported. Over time, the developer forgets about entries they used many versions ago, and an incompatibility comes up with a new version (parsing, internal layout and structure, size/length limitations, etc...). Or they forget, and reuse old names for a different purpose - but since the upgrade preserved the original, those variables now contain data that is not valid for the new useage.

Those shared folders or places storing mixed data you mentioned - if you think about it, that's exactly what the old installation represents if you're installing a new version right on top of it.

[admin]

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.

Yep, I still think this is needed, but I'd prefer if it were called <scriptpath>. <xyspath> is just a little too similar to <xypath>, which make debugging difficult, and could cause problems if the user accidentally drops the s.

I did a quick shot at a new command "self", as an alternative to <xyspath> etc. It would look like this:

Code: Select all

        ' syntax: self OutputVar, [info]
        '   info: file = current script file (empty if none)
        '         path = current script file's path (app data if none)
        '         script = current script
        ' example:
        '   self $a, path; msg $a;

Of course other infos could be added. Maybe "self" is not a good choice for the name.

[PeterH]

As name, maybe xyfiles? Or, if in future other info could be retrieved from XY, xyinfo?
And the info-operand specifies, what info is to be retrieved...

[jacky]

As name, maybe xyfiles? Or, if in future other info could be retrieved from XY, xyinfo?
And the info-operand specifies, what info is to be retrieved...

I like self more than xyinfo, because the later sounds too general. Using "xyinfo $var, path" doesn't link this in any way to the current script file, whereas self kinda does, obviously. If this could go more global and not limited to the current script (file), I'd suggest something more like getinfo then...

Side note: I'd like a new var <ver> with the current XY version ? Would be nice for my backup script (instead of having to go select the EXE to get <curver> to work); plus (later on) one could write a script and use it to ensure compatibility in regards to syntax changes, etc

[admin]

Side note: I'd like a new var <ver> with the current XY version ? Would be nice for my backup script (instead of having to go select the EXE to get <curver> to work); plus (later on) one could write a script and use it to ensure compatibility in regards to syntax changes, etc

Ok, but <xyver> would be more in line with <xypath>, <xydata>, <xyexe> ...

I also thought about getinfo for that command but then I found self cuter. A separate command getinfo could still be added for all types of info...

[jacky]

Sure, should have thought of it myself , <xyver> is even better!

And AFAIC I have no problem with self, and yes later on for more global stuff a new command getinfo could still be added... if there's a need for it.

[j_c_hallgren]

Of course other infos could be added. Maybe "self" is not a good choice for the name.

First, the term info does not have a plural form so whether it's one item or millions, just use info...in above usage, it would be more correct to say 'info operand values', IMO.

Second, the name "self" as a command left me going "huh?"...Getinfo seems to describe it better, but still may not be ideal.

[admin]

Of course other infos could be added. Maybe "self" is not a good choice for the name.

First, the term info does not have a plural form so whether it's one item or millions, just use info...in above usage, it would be more correct to say 'info operand values', IMO.

Second, the name "self" as a command left me going "huh?"...Getinfo seems to describe it better, but still may not be ideal.

Ok, most commands are verbs (open, set, load...) but some are not (strlen, strpos, text...), so why not self? In PHP it would be "this". The point is that the script spills out info about itself.

[PeterH]

... The point is that the script spills out info about itself.

That's the difference? It spills out info about itself - but it doesn't spill out itself

[admin]

... The point is that the script spills out info about itself.

That's the difference? It spills out info about itself - but it doesn't spill out itself

You must think object-oriented!

Code: Select all

$a = self.file;
$a = self(file);
self $a, file;

It's all the same, essentially. Free your mind...

[PeterH]

Don't get me wrong: the first 2 versions are not object oriented - they simply are REXX!
OK: the second should be a=self("file")

To be true: the function-type would be very nice! This would have been the interface I wished you had made...
(I hope "file" could be abbreviated to "f"?)