Script Configuration Discussion

[klownboy]

Moderator's Edit: topic split from http://www.xyplorer.com/xyfc/viewtopic. ... 59#p135459

Yes, the method I had used in a few scripts calls for reading ini file and looping through the toolbar() to get a name match. You may not like these self-modifying scripts, but in this case, it's only performing the quick update of the index number and it's very fast even on the first run and after that, it's skipped. It was probably you or highend that I got a variation of this code.

Code: Select all

		$ctbindex = "unknown";
      $toolbar = toolbar();
      $self = self("file");
//*** Determine & set CTB index [$ctbindex above] based on CTB name
	if($ctbindex LikeI "unknown") {
		$name_CTB = ctbname();
		foreach($button, $toolbar, ",") {
         if(substr($button, 0, 3) LikeI "ctb") {
           $ctbI = trim($button, "ctb", "L");
           if(ctbname( , $ctbI) == "$name_CTB") {
	        $ctbindex = $ctbI; break;
           }
         }
       }
		$content = replace(readfile($self), "unknown", "$ctbindex", , 1, 1);                                   
		// or use $content = regexreplace(readfile($self), "(\$[c]tbindex\s?=\s?"")([^""]+)(.*)", "$1$ctbindex$3");
      writefile($self, $content);
   }

Yes, that's a good idea simulating the button click when using a CKS. I should try that too...I assume it should cycle the ctbicon as you click the shortcut key.

Personally, I don't think I'd want the script to activate a thumbnail view if it wasn't already in one. There may be too many situations where you inadvertently press the CTB or CKS and not be in a folder that has images type files you want to see in a thumbnail view. So you end up getting XY generating unnecessary thumbnails.
Thanks.

[TheQwerty]

You may not like these self-modifying scripts

Ewwww!!! Nope.. I refuse to do that. There's no reason to ever do this!

<code_snippet>
I don't get this code... You can determine the index using Get('Trigger', 'ctbindex') which returns -1 when not triggered by a CTB. But I cannot think of any scenario where it would fail but ctbname() would still work?

Plus this won't work for anyone using the script without saving it to a file - which I feel is more important.

[klownboy]

I figured you were dead set against the self modifying scripts, but then again we're both not so keen on having a ton of permanent variables rather.

I tried the get(trigger, ctbindex) and as you said it returns '-1' when used outside CTBs. CTBnme() will always work outside a CTB as long as you supply the index and will error if you don't. I've got that before.

If the script is called from outside a CTB you *have* to state a button index, else you will get an error message.

Same line in help exists for ctb /name/icon/state.

That little code piece for determining the index may very well have been created /used before the existence of get(trigger, ctbindex) and honestly I forgot about get(trigger, ctbindex) the other day. Obviously it was intended to be run from a CTB and to get the index based on CTB name only.

If it boils down to determining direction based on location, why not use: if(gettoken(controlatpos(),"1","|") != "TB") {... Without the gettoken you can even determine index (e.g., TB|31). So you get the location (TB or not) and get the CTBindex if TB is valid. The question is saving the index for future runs when the script is implemented from outside the toolbar.

I see your point about this not working if it's not saved as an xys file. But then again, when a script get longer than 5 or 6 lines I'd much rather have it in a separate file than polluting the XYplorer.ini file. So I wouldn't see that as a problem really.

[highend]

There's no reason to ever do this!

Can't agree. My first self modifying xy script is how old, two years? Never had a single complain that any of them were not working correctly. It only comes down if you know how to do it in a safe way.

Placing "full" scripts directly into UDBs or UDCs: That's something I'd never do, unpleasant to upgrade, difficult to debug (in comparison with a .xys script with an editor with e.g. syntax highlighting)

[TheQwerty]

@klownboy: My confusion with that code was because there is no index being passed to ctbname. Sure I could iterate over the 64 CTBs checking each for a name which matches one of the states, but this hardly seems worth the effort if I'm honest.

There's no reason to ever do this!

Can't agree. My first self modifying xy script is how old, two years? Never had a single complain that any of them were not working correctly. It only comes down if you know how to do it in a safe way.

That's not a reason to do it at all - it's an excuse for not changing a past mistake. Get/SetKey existed before Read/WriteFile, so there was never any sensible reason to go about rewriting the script file in this manner.

Placing "full" scripts directly into UDBs or UDCs: That's something I'd never do, unpleasant to upgrade, difficult to debug (in comparison with a .xys script with an editor with e.g. syntax highlighting)

Sure, but as this thread illustrates a script doesn't always start life "full". Plenty follow a path of growth and it's hard to argue that a single command should be placed in its own script file; same with a single line. However after many small incremental changes it can sometimes be difficult to have the discipline and foresight to know when to take the script and make it a file instead.

[highend]

That's not a reason to do it at all - it's an excuse for not changing a past mistake. Get/SetKey existed before Read/WriteFile, so there was never any sensible reason to go about rewriting the script file in this manner.

There was only one reason: A self contained script that doesn't even need an .ini file (or one / more permanent variable(s)) to store a few settings

it's hard to argue that a single command should be placed in its own script file; same with a single line

I was talking about "full" scripts, not simple one liners...

[PeterH]

OK: I can only tell my personal point of view...

...but I must say: I've learned to avoid dynamically modifying scripts.

And as you can write and read a file, may it be .ini or something else, and even write it to the name and path (concatenated e.g. with .ini) of the current script, there are enough facilities to accomplish this.
(And I don't think it's more difficult than modifying the current script.)

But as I said: just my POV.

[klownboy]

Maybe as a united group of XY scripters, we should consider having a "XyUserScripts.ini" file in which XY scripts could save setting or values and later refer to it to retrieve values stored within it. Some people might use only certain scripts so their ini file might be quite small with only a few values. Others might use it extensively and have many values stored there. SC setkey and getkey already exists to do just that. It minimizes the permanent variables and is always extremely fast with XYplorer.ini so I'm sure it would be for a relatively small ini file. At least this way scripters wouldn't feel so guilty saving a value(s) to new and separate ini files, since the settings or data would be in one multi-purpose scripters ini file. In some ways similar to user functions, but in this case, it's used just to save settings for use in scripts.

Code: Select all

setkey value, key, section, [INIfile], [flags]
setkey 33, CTBindex, WallGallery, XYuserScripts.ini

We would all or at least majority have to agree on a ini filename and settings storage, but I don't see why something similar to this wouldn't work.

[PeterH]

Again my personal view:

I rather don't like multi-purpose ini-files. I'm all for a small ini per script, with name and location being built from name and location of the script file. This way this ini is "logically bound" to this one script.
You even can copy the script to another location, or to another name, and it will automatically use a different(!) ini file, with different values contained.

And absolutely no collision with any other script...

[klownboy]

Well, I knew when I wrote the suggestion of a common scripting ini file for storing settings, there would be disagreements. As you mentioned, everyone has their personal preferences on various aspects of scripting including where to store information. Though I don't see how someone even reasonably knowledgeable on scripting, and they are the only people who would utilize a XyUserScripts.ini file, could damage another user's data/settings especially since the "section" referred to with setkey would be the name of the script itself. The other way to view it is, if you don't like it, you don't have to use it or you could to modify the script to save the setting elsewhere like a PV or separate ini file.

...but I must say: I've learned to avoid dynamically modifying scripts.

There are a few scripts floating around XY's forum that self modify each and every time they are run and I would agree with you there. I don't particularly like that. But, a simple value stored once and only once, when a section of the script is run for the very first time, I think that's totally different, and that's the case in the script we were originally discussing. Thanks.

[TheQwerty]

Again my personal view:

I rather don't like multi-purpose ini-files. I'm all for a small ini per script, with name and location being built from name and location of the script file. This way this ini is "logically bound" to this one script.
You even can copy the script to another location, or to another name, and it will automatically use a different(!) ini file, with different values contained.

And absolutely no collision with any other script...

While I too appreciate a portable design, I am curious if any users share a single script file among multiple users; perhaps running it from a network share? Because I'd imagine for them the portable design is a headache and they might prefer per-individual configurations.

Which leads to the question of is <xyscripts> or <xydata> a more appropriate location for script settings?
For most the former is probably in the later, but there's nothing saying it has to be.


Reflecting on my own scripts... I used a technique in my Code Preview script that I really liked, but felt was still a work in progress.

• Read the ScriptRetainPVs setting from <xyini>. I viewed this as infrequently changed, and used the value without care for its freshness.
• If ScriptRetainPVs is true, I used permanent variables named like so: $P_<author>_<script>__<keyName> i.e. $P_THEQWERTY_PREVIEW_CODE__OPTIONS
• If ScriptRetainPVs is false, I used an INI file: <xyscripts>\.config\TheQwertysSciprts.ini
• I tried to combine as many of my settings as I could into a single delimited key-value to limit the number of keys I needed. This was intended more to limit PVs, but treating the INI the same led to simpler code.
• My thought was to share the INI file across my scripts, with each script getting its own section.
• To further augment the logic, I provided a 'User Tweaks' script which set global variable settings that controlled the above behavior:
  • $G_FORCE_INI_USE - If true, ignore ScriptRetainPVs and always use the INI.
  • $G_INI_FILE - Set to the path to the INI file to use for this script's settings.
  • $G_INI_SECTION - Set to the section name for this script's settings.
  If memory serves, or at least in hindsight, I don't like this 'User Tweaks' script, as it means hardcoding the values within the script file.

A big piece that is missing from that is handling upgrading the script and versioning of the configuration data. I fortunately haven't had to deal with that yet.

I still like the general idea and flexibility of this and would like to update/modularize it for this newer UDF world that we now live in.
Unfortunately, this newer world still has the same old time-constraints.

[klownboy]

Hi TheQwerty, so at some point you were thinking along the lines of a common ini file but common only to you. So here we're talking of expanding that thought to have a XyUserScript.ini common to users. Only relatively experienced scripters would use it anyway. Inexperienced script writers are typically not at he point where they are saving settings anyway.

We would layout the rules of use - purpose / format (templates) and require strict adherence to the rules if one is to use the common ini file. If they don't, a moderator could advise the preparer to change the script or delete the script. The intent should be to store very simple data or settings like your WallPic or Wallgallery script, not for large amounts of information. If that's the case, the scripter should write to a separate/individual ini file based on the script name. We wouldn't want the file polluted with excessive data by one abuser. I think it can be totally independent of whether the user has PV settings saved between sessions. Obviously that's still a personal choice that a scripter always has. He can always write his scripts to check if PVs are saved and save information as a permanent variable. I'm looking at this as another option a scripter has if he's trying to avoid making more permanent variables.