XYplorer Beta Club

Mesh wrote:

admin wrote:
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.

jacky wrote: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.

admin wrote:
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.

Mesh wrote:

admin wrote:
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 wrote:
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).

TheQwerty wrote:

jacky wrote: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.

        ' 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;

PeterH wrote: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 wrote: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 wrote:Of course other infos could be added. Maybe "self" is not a good choice for the name.

j_c_hallgren wrote:

admin wrote: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 wrote:... The point is that the script spills out info about itself.

PeterH wrote:

admin wrote:... 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

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