Date info in status bar

[admin]

So here's is a thought I had early on, but that seemed odd at the time : how about using a script there ?? ...

OnEvent Scripting, elegant idea! OnSelectFile, OnStartUp, OnExit, OnDblClickEmpty, etc. ... Yes, it should happen. But it needs an interface to define/associate the scripts; and also probably a separate storage file, because it does not fit into udc.dat or any of the other *.dat. Well, there might be a way to fit it into the UDC interface... anyway it's not for now. But later, yes...

[jacky]

So here's is a thought I had early on, but that seemed odd at the time : how about using a script there ?? ...

OnEvent Scripting, elegant idea! OnSelectFile, OnStartUp, OnExit, OnDblClickEmpty, etc. ... Yes, it should happen. But it needs an interface to define/associate the scripts; and also probably a separate storage file, because it does not fit into udc.dat or any of the other *.dat. Well, there might be a way to fit it into the UDC interface... anyway it's not for now. But later, yes...

- an interface : yes, but the question would be, do we want a dedicated interface for this ? Because for "new" events it might make sense, but for others it might be better to stay as-is. I mean there's already an action for dbl-click on Tab, maybe just an extra item that would reveal a textbox where the user can specify the script name (, script label) to run would work.

Then, the same thing could be added on Startup & Exit for those events, etc

- a storage file : well, seems to me it could fit inside the INI, no?

BTW slightly off topic, but with the new syntax for getkey/setkey one might need a delkey or something, to do some cleaning from time to time ?

[admin]

So here's is a thought I had early on, but that seemed odd at the time : how about using a script there ?? ...

OnEvent Scripting, elegant idea! OnSelectFile, OnStartUp, OnExit, OnDblClickEmpty, etc. ... Yes, it should happen. But it needs an interface to define/associate the scripts; and also probably a separate storage file, because it does not fit into udc.dat or any of the other *.dat. Well, there might be a way to fit it into the UDC interface... anyway it's not for now. But later, yes...

- an interface : yes, but the question would be, do we want a dedicated interface for this ? Because for "new" events it might make sense, but for others it might be better to stay as-is. I mean there's already an action for dbl-click on Tab, maybe just an extra item that would reveal a textbox where the user can specify the script name (, script label) to run would work.

Then, the same thing could be added on Startup & Exit for those events, etc

- a storage file : well, seems to me it could fit inside the INI, no?

BTW slightly off topic, but with the new syntax for getkey/setkey one might need a delkey or something, to do some cleaning from time to time ?

fit inside the INI: yes, within limits (line feeds must be handled somehow and there's a maximum size for values in an INI).

delkey: delsection, enumsections, enumkeys... there's always room for expansion...

[PeterH]

fit inside the INI: yes, within limits (line feeds must be handled somehow and there's a maximum size for values in an INI).

Maybe a split between definition and script? In a section of the INI define actions and associated scriptnames:
OnSelectFile scriptname
OnAbc... scriptname...
On...
and the scripts are in the normal script-directory (or fully qualified)?

delkey: delsection, enumsections, enumkeys... there's always room for expansion...

Sounds pretty good! But to be really useful enum... need next scripting-level?

[j_c_hallgren]

fit inside the INI: yes, within limits

Maybe a split between definition and script? In a section of the INI define actions and associated scriptnames:
OnSelectFile scriptname
OnAbc... scriptname...
On...
and the scripts are in the normal script-directory (or fully qualified)?

And how about if it were handled similar to Config for Startup Path or Thumbnail Cache? You have the various events listed and then user defines what script name, if any, to execute -or- maybe just a one-line set of commands in-line there? And this would then be stored in INI.

[jacky]

fit inside the INI: yes, within limits (line feeds must be handled somehow and there's a maximum size for values in an INI).

Oh right, you had actual script in mind! I have to admit, I only had in mind the need for the name of the script file to load, and maybe the script label to execute, like the "Load Script File" UDC for example, not the "Run Script" one.
If we're going actual embedded scripts, then yeah an events.dat or something might be needed, yes.

delkey: delsection, enumsections, enumkeys... there's always room for expansion...

Well, of course the full package is always around the corner, yes, it's just that when using this for something else than XY settings, right row if we want to set/remember tmp values or something, once done we can only "empty" them, meaning leave a "Keyname=" line in the INI file, but we have no way to actually remove it, that's all.
Seems to be it could be useful, without diving into enumkeys & co which would probably not really work until Scripting 2.0 anyways...

[j_c_hallgren]

And when it comes to deleting keys from INI, I'm wondering if there is some mechanism to prevent us from clobbering required XY keys? So are any user defined keys kept in a "user/private" key section or similar?

[jacky]

And when it comes to deleting keys from INI, I'm wondering if there is some mechanism to prevent us from clobbering required XY keys? So are any user defined keys kept in a "user/private" key section or similar?

hmm.. you mean user adding keys/sections inside XY's config INI file ?? Cause if so, and I haven't actually checked that one yet, but I don't thin one should do that, because I'm thinking XY wouldn't keep them, as its writing (saving settings) procedure probably doesn't involve reading the actual content of the INI, but only writing down the current (=from memory) values.

I might be completely wrong on that one, but I'm thinking saving "new" sections/keys inside an XY INI file will see all of those things gone the next time XY saves its settings.

I was myself only talking about other INI files, in the present case completely new INI files created and used only by & for a given script.

[j_c_hallgren]

jacky, you're much closer to this than I'll likely be, but just wanted to bring up that aspect (deleting and/or user keys) for thought/discussion...

[Muroph]

And when it comes to deleting keys from INI, I'm wondering if there is some mechanism to prevent us from clobbering required XY keys?

I like the 'delkey' and 'delsection' idea, but some protection like this is really important.
Imagine if for some reason (like a bad script) you deleted a whole section of your config ini and xy crashed after that.
That section would be lost.

I might be completely wrong on that one, but I'm thinking saving "new" sections/keys inside an XY INI file will see all of those things gone the next time XY saves its settings.

It's true. I've seen it happen.

[TheQwerty]

With all this Getkey/Setkey custom INI file talk I think we really need a new variable <scriptPath> which if called from a script file would contain the path to that file, otherwise it would be blank.

This way we could use custom INI files that stay with the scripts that use them.



Perhaps there should be a "security" setting/level associated with certain commands, so that a new user could have it set high and XY would prompt before running a script with certain commands (SetKey followed by Save Settings, Deletes, etc.)?

That would allow the users who aren't very confident with scripting to run something written by someone else without having to be terrified of it destroying things. Plus it might protect the careless and fancy free script writers among us from being reminded that Undo is still on the road map.

Or perhaps Step Through Script is comforting enough?

[jacky]

With all this Getkey/Setkey custom INI file talk I think we really need a new variable <scriptPath> which if called from a script file would contain the path to that file, otherwise it would be blank.

This way we could use custom INI files that stay with the scripts that use them.

Well, I guess such a <scriptpath> variable could be something, since script files can be executed from about anywhere, indeed. But as far as XY goes, and it is a portable app, one might also assume that all scripts should be located ideally under <xydata>\Scripts

If that's the case, simply stating "filename.ini" will put the file in <xypath> I think, "Scripts\filename.ini" would put it with scripts (if <xydata> and <xypath> are the same), and of course you could use "<xydata>\filename.ini"

Of course, if you intend to use a script located somewhere outside of XY's paths, and want to have its "settings" (to the script) saved in that same place, a <scriptpath> might be required -- but that wouldn't be some standard behavior I'd say. I mean, I feel that for "standard" script use, using a simple filename (or prefixing it with <xydata>) should be enough, no?

Or perhaps Step Through Script is comforting enough?

I'd say it is, because otherwise Don would have to go through each of the XY's command (including the whole list on CKS) to assign such a "security level", because there's some dangerous command there (eg. some delete operations, etc), then moveto could be seen as a potential risk as well, all the open(with) too, settingp, etc

I think the stepping mode is enough to allow one to keep an eye on what's going on.

[admin]

With all this Getkey/Setkey custom INI file talk I think we really need a new variable <scriptPath> which if called from a script file would contain the path to that file, otherwise it would be blank.

This way we could use custom INI files that stay with the scripts that use them.

Well, I guess such a <scriptpath> variable could be something, since script files can be executed from about anywhere, indeed. But as far as XY goes, and it is a portable app, one might also assume that all scripts should be located ideally under <xydata>\Scripts

If that's the case, simply stating "filename.ini" will put the file in <xypath> I think, "Scripts\filename.ini" would put it with scripts (if <xydata> and <xypath> are the same), and of course you could use "<xydata>\filename.ini"

Of course, if you intend to use a script located somewhere outside of XY's paths, and want to have its "settings" (to the script) saved in that same place, a <scriptpath> might be required -- but that wouldn't be some standard behavior I'd say. I mean, I feel that for "standard" script use, using a simple filename (or prefixing it with <xydata>) should be enough, no?

Or perhaps Step Through Script is comforting enough?

I'd say it is, because otherwise Don would have to go through each of the XY's command (including the whole list on CKS) to assign such a "security level", because there's some dangerous command there (eg. some delete operations, etc), then moveto could be seen as a potential risk as well, all the open(with) too, settingp, etc

I think the stepping mode is enough to allow one to keep an eye on what's going on.

I'd say so too. You can already disable "Quick scripting", and I might add another option to disable any form of scripting. I'm also thinking about publishing a "Home Version" (as opposed to "Professional") of XY which will have no scripting at all.

[j_c_hallgren]

I'm also thinking about publishing a "Home Version" (as opposed to "Professional") of XY which will have no scripting at all.

Or maybe a "Basic" vs "Premium"? Since a business user may wish to have limited vers for some employees and having that as "Home Vers" sounds odd...

I'd thus also suggest a price differential where user could upgrade to higher vers for that diff (plus a small add-on to encourage combined purchase plus offset any cost to do so)...but I presume you'd already planned that?

[TheQwerty]

Well, I guess such a <scriptpath> variable could be something, since script files can be executed from about anywhere, indeed. But as far as XY goes, and it is a portable app, one might also assume that all scripts should be located ideally under <xydata>\Scripts

If that's the case, simply stating "filename.ini" will put the file in <xypath> I think, "Scripts\filename.ini" would put it with scripts (if <xydata> and <xypath> are the same), and of course you could use "<xydata>\filename.ini"

Of course, if you intend to use a script located somewhere outside of XY's paths, and want to have its "settings" (to the script) saved in that same place, a <scriptpath> might be required -- but that wouldn't be some standard behavior I'd say. I mean, I feel that for "standard" script use, using a simple filename (or prefixing it with <xydata>) should be enough, no?

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...