Is it possible to call menu items directly?

[Stef123]

Yes, thanks Sammay,
no problem here, with my config-settings I don't need the initialize part. I was just wondering - hypothetically thinking - how to go about should I really need it some day (or similar stuff in a different script). What TheQwerty said about executing the item straight away made sense to me - why would a hidden entry pop a menu if I call one visible command only?

BTW, Cleanup Residue is a real boon - I run it once a week and it always removes a lot of clutter when I check up on it in the thumbnails folder.

ed.
What still throws me off with those colons, I have been able to load a bunch of scripts without them, never encountered a problem. Maybe it has to do with calling sub-scripts?

[bdeshi]

What still throws me off with those colons, I have been able to load a bunch of scripts without them, never encountered a problem. Maybe it has to do with calling sub-scripts?

where and how?

[Stef123]

What still throws me off with those colons, I have been able to load a bunch of scripts without them, never encountered a problem. Maybe it has to do with calling sub-scripts?

where and how?

Well, at some point I realized that I don't have to define a "UDC > Load Script file" first, then enter the #1234; code into CTB. What I've been doing ever since is stuff like this:

Code: Select all

"Extension Filter...Ctrl Shift ."  load "<xyscripts>\FilterExtensions.xys";
"Better File Selector...Ctrl Shift M"  load "<xyscripts>\BetterFileSelector\BetterFileSelector_v1.2.xys";

[TheQwerty]

Best practice is to give all of your scripts a caption and a label:

Code: Select all

"Caption : label" echo 'hi';

Then use the label in subs and loads. However, when it comes to '_Initialize' and '_Terminate' they are special cases and cannot take that form.

Granted, while it is easy to think of it in terms of "Caption : Label" the truth of the matter is the possibilities are more like:

Code: Select all

"Caption|Icon|State : Label"
"Caption|Icon : Label"
"Caption||State : Label"
"Caption : Label"
"Label|Icon|State"
"Label|Icon"
"Label||State"
"Label"

Since if there is no label the caption becomes the label. (Note that I didn't follow this terminology in that thread discussing visibility of scripts.)


One pattern I tend to use with '_Initialize' is the following:

Code: Select all

"_Initialize"
  // when dealing with multiple '_Initialize' scripts
  // you'll want to give this variable a more unique name.
  Global $G_INITIALIZED;
  if (! $G_INITIALIZED) {
    // ...
    // initialization code
    // ...
    $G_INITIALIZED = true;
  }

"Item A : a"
  // Ensure that _Initialize ran.
  Sub '_Initialized';
  Echo 'a';

"Item B : b"
  // This script does not need to be initialized.
  Echo 'b';

"Item C : c"
  // Assumes _Initialize already ran.
  // Not actually part of the pattern but for the next example. ;)
  Echo 'c';

In some respects this defeats the purpose of '_Initialize' and it really started as a way to support versions of XY from before '_Initialize' was introduced, but this pattern ensures '_Initialize' is run for those scripts that rely on it.

As I mentioned, you can explicitly call '_Initialized' if need be. Given the above script you might have problems calling 'Item C' directly since it incorrectly assumes that '_Initialize' ran, so when loading it externally you could do (assume the script is '<xyscripts>\demo.xys'):

Code: Select all

Load 'demo', '_Initialize', 'f';Load 'demo', 'c', 'f';
// or if you wanted to show a custom menu:
Load 'demo', '_Initialize', 'f';Load 'demo', 'c;b;a', 'f';

In both of these cases the '_Initialize' script is called first and then the specified scripts are called.

[klownboy]

If you want to ensure '_Initialize' is run before one of the loaded labels then just run it before the load.If a particular script counts on '_Initialize' then have it call '_Initialize' to ensure it runs.If you want to minimize '_Initialize' to only running once use a global/perm var to ensure it only runs once - even if called by multiple scripts that rely on it.There's so many solutions to ensure '_Initialize' is run that I don't see any reason to make it more confusing.

All good ideas TheQwerty, but sorry they all come across as work-arounds for an issue with "_Initialize". I don't see them as a not a proper solution. "_Initialize" being a special label or caption devised by Don to be run when a script resource file was run UNLESS a specific script label is called out, it's bypassed. That's it. We should not have to specifically run "_Initialize" in a separate load before loading other labels. Yeah I know it's complicated as it is, but "_Initialize" running at the start of the script when it's specified in a list of labels or running when just the resource file is called, shouldn't be. That should be the rule and I think that was the original intent. Granted, Don's not going to want to do anything about it. I understand that because it's a can of worms, but that does not make the way it currently works right.

Enough on that topic, but speaking of topics could one of the Administrator (sorry I meant) moderators move this discussion from Stef123's entry here [url] to "Tips...". It really should be a general question/discussion on calling out labels.
Thanks,
Ken

[bdeshi]

What still throws me off with those colons, I have been able to load a bunch of scripts without them, never encountered a problem. Maybe it has to do with calling sub-scripts?

where and how?

Well, at some point I realized that I don't have to define a "UDC > Load Script file" first, then enter the #1234; code into CTB. What I've been doing ever since is stuff like this:

Code: Select all

"Extension Filter...Ctrl Shift ."  load "<xyscripts>\FilterExtensions.xys";

they have ; at the end.

btw, you can either begin the script with :: or end it with ; . The presence of either will make XY process the text as script. (and they aren't mutually exclusive)

[Stef123]

Thanks Sammay,
what got me confused - I did have the semi-colon ; at the end, and yet it did not bring the same result, the cleanup-dialog came up broken, without captions. I needed to prefix load with ::load to get it right. Now however, it works fine, just the way you describe it - but I swear this was not the case before

Ken is right, this whole label thing does not really belong here, I should have asked in a more generic section. No objections to moving it over or deleting it altogether if it's redundant.

[klownboy]

What still throws me off with those colons, I have been able to load a bunch of scripts without them, never encountered a problem. Maybe it has to do with calling sub-scripts?

Hi Stef123, interesting that you had mentioned this the other day. I had stumbled across this in the help file a few days ago.

Hidden scripts can be executed but are not shown in the script file's popup menu. To hide a script simply prefix an underscore to the caption or label (a hidden script does not need a caption anyway). For example, create a script file "date.xys" in application data path with the following contents:

// this is in script file "date.xys"
"_date"
msg "<date yyyy-mm-dd>"

I've used only the single caption no label (or single label no caption) for hidden scripts in script files and they seem to work fine when called from other areas in the script file. It's when calling subs which are not hidden that I have to add the " : caption" to call them within the script file using SC sub. So when the label/caption is hidden like "_HIDDEN", this is considered to be the label since as Don stated above "a hidden script does not need a caption anyway". Where else could you go to have this much fun!

[Stef123]

So when the label/caption is hidden like "_HIDDEN", this is considered to be the label since as Don stated above "a hidden script does not need a caption anyway". Where else could you go to have this much fun!

Hehe, you know, this forum is the right place for embarrassing confessions, such as me getting easily carried away with optimizations to an extent that my tools take over. Happens every so often when business is slow and I have no clients to victimize, so it's my own workflows that get under close scrutiny.

If _Hidden is considered to be the label, what is considered to be the label for non-hidden entries that do NOT have a label? I tried variations like

Code: Select all

Build Thumbnail Cache
Build Thumbnail Cache [current folder && subs]
Build Thumbnail Cache [current folder && subs]|<xyicons>\refresh_03.ico

but none of them pulls the trigger. Index-number seems to be the only way to call these items?

[TheQwerty]

I tried variations like

Code: Select all

Build Thumbnail Cache
Build Thumbnail Cache [current folder && subs]
Build Thumbnail Cache [current folder && subs]|<xyicons>\refresh_03.ico

but none of them pulls the trigger. Index-number seems to be the only way to call these items?

This appears to be a bug in XY.

The label should be: Build Thumbnail Cache [current folder && subs]

Unfortunately the script does not also have a label which you could use instead.
Until the script or XY is changed your only option is the index number.

[klownboy]

Hi again Stef123, feel free to bastardize the script in any way you'd like including modifying the menus (i.e., adding labels or modifying the caption). I mentioned before if you're interested in simply running one particular menu item such that no menu at all is displayed, then I'll gladly help out. Tell me which one, and I can modify the script up and send it to you via PM. I just didn't want to modify the script in the thread for specific need of one if that makes sense. Or you can do it too (obviously that's what you're currently doing) and we can compare notes.

Edit: By the way, you'll notice there are a couple of non-hidden menu items which have labels because I had to refer to them elsewhere in the script such as:

Code: Select all

"Thumbnail Cache Clean-up [by folder using cache DB]|:cut : THUMB_DB"

You should be able to use a similar syntax if you need to refer to a particular script. I know that works.

[Stef123]

@ TheQwerty
Thanks for confirming the bug - good to know I didn't trip up on some syntax issue.

@Ken
I don't remember if I mentioned it somewhere above - after trying to figure it out and just before making use of your PM offer, I reverted my script changes back to the default, and decided to go with index-calls instead. Allows me to keep using your default script updates and not having to worry about overwriting my custom version of your script.

And should you decide to wedge new items between existing ones, well, index values are more likely to make sense to me than searching for end-of-line labels, provided I still remember this connection a few months down the road. So ATM, I am quite happy, got all my favorites harnessed in one CTB and all index calls working as I hoped for. THANKS.

[PeterH]

Not sure where the bug really is...

Documentation says:
(5) Within a caption you may define a label that allows you to execute a script from a file directly.
So it seems you must define a caption to be able to call a specific script. The label is the part behind " : ".

But:
To hide a script simply prefix an underscore to the caption or label (a hidden script does not need a caption anyway).
This seams to say that for a hidden script Label and Caption are (about) the same. (I.e.: no " : " neccessary!)
(Though I think I've seen hidden scripts with "Some caption text : _label" ?

I think best might be to define: the text specified for Caption is the default for label, as long as there's no explicit Label. This would help both worlds, i.e. hidden and non-hidden scripts?

(Not mentioned, but included: as hidden labels can be shown in menu by explicitely naming them in a list, it can make sense to give them a caption.)

[TheQwerty]

Some best practices for script writers...

Always define both a caption and a label: "Caption : label"
Only reference the script in load/sub via its label.

If the script is not meant to be triggered by itself - use the disabled state: "Caption||4 : label"
This will make it impossible to select when shown in a menu.
Note that the script can still be triggered via load/sub so if you require certain conditions be met before running this script build some intelligence into the script. Such as:
- Check for the conditions you require and if they are not met run the required script before continuing.
- Prompt for missing but necessary values.
- Exit gracefully via error dialog.

If you don't want the script to appear in a menu by default, but still allow it when included in load - underscore the label: "Caption : _label"

If you don't want the script to ever appear in a menu - underscore both the label and caption: "_Caption||4 : _label"
Technically you only need to underscore the caption but underscoring the label makes it easier to recognize that the script is hidden when you see it used in a load/sub. Plus keeping the consistency is nice.
I recommend still using the disabled state here just in case the behavior of hiding changes.

[PeterH]

Some best practices for script writers...
...
If the script is not meant to be triggered by itself - use the disabled state: "Caption||2 : label"

I think a typo here: disabled should be 4?

If you don't want the script to ever appear in a menu - underscore both the label and caption: "_Caption||2 : _label"

- I don't find this documented
- if never shown in a menu a caption will never be used. But you have to specify it to prefix "_" strange.

The latter is often a characteristic of a hidden script - specified by "_identifier". With the "identifier" being documented as "caption or label"
To hide a script simply prefix an underscore to the caption or label (a hidden script does not need a caption anyway).
So I think for these situations it isn't really clean.

For the rest I'm with you.