Is it possible to call menu items directly?

[Stef123]

[split from http://www.xyplorer.com/xyfc/viewtopic. ... 20#p118269]

Is it possible to call menu items directly, from a CTB dropdown? In my endless quest to consolidate commands into the tightest interface possible, I'd like to leave out stuff I rarely use, and group the rest together with other tasks.

[bdeshi]

An example:

Code: Select all

::load "thumbnailmaintenance", "_Initialize;THUMB_DB";

In the xys file, each menuitem has a :label at the end of it's caption, like this:

Code: Select all

"Thumbnail Cache Clean-up [by folder using cache DB]|:cut : THUMB_DB" ---> THUMB_DB is the caption.

Just use these labels, separated by ; , with SC load. Another example

Code: Select all

::load "thumbnailmaintenance", "_Initialize;THUMB_DB;THUMB_REFRESH";

[Note that I have thumbnailmaintenance.xys in <xyscripts>, so the basename (with path relative to <xyscripts>) is all that's required.]

btw, all _Initialize does is basically change a setting ("Create all thumbnails at once") in <xyini>, and optionally prompts to save settings. If that's already set, you can skip _init.

Code: Select all

::load "thumbnailmaintenance", "THUMB_DB"; //example

In this case, when you call just one subscript, it will come up directly without displaying a one-item popumenu first.

[klownboy]

What Sammay said above is correct. You'd have to do some testing since there are 4 scripts labels near the end of the file(i.e., "_PAPER_CHECK", "_THUMB_SIZES", "_viewDATA", "_DBsize", "_DATA") that are referred to by the various cleanup or rebuild methods. These scripts within the resource file are obviously needed and it was set that way such that these sections were not repeated 4 or 5 times.

If you have on particular method you'd like to break apart such that it immediately runs, let me know and I can take a look. I probably wouldn't post it though but get it to you via PM.

[Stef123]

Thank you Sammay,
very good explanation - perfectly geared towards my skill level. Since I have "Create all thumbnails at once" turned on at all times, I can call items directly without the _Initialize part *sigh of relief*

@Ken
if I read you correctly some functions call modules within the script that belong to a different sub-item menu heading/ caption. So this may or may not work depending on what items I choose to include in my CTB.
Thanks for offering to help out via PM. Very much appreciated.

[bdeshi]

You'd have to do some testing since there are 4 scripts labels near the end of the file(i.e., "_PAPER_CHECK", "_THUMB_SIZES", "_viewDATA", "_DBsize", "_DATA") that are referred to by the various cleanup or rebuild methods. These scripts within the resource file are obviously needed and it was set that way such that these sections were not repeated 4 or 5 times.

@Ken
if I read you correctly some functions call modules within the script that belong to a different sub-item menu heading/ caption. So this may or may not work depending on what items I choose to include in my CTB.

calling any subscript takes care of any sub s within. label-loading will work even if those "innards" aren't explicitly included in the list of labels-to-load.

[klownboy]

calling any subscript takes care of any sub s within. label-loading will work even if those "innards" aren't explicitly included in the list of labels-to-load.

I was hoping that was the case Sammay, but I wasn't positive so I figured I have to test to check it out. Thanks Sammay.

[Stef123]

Gets better all the time. Even though I load only a small part, it will nonetheless remember where it came from and call home if necessary.
Thank you both.

[bdeshi]

@stef, glad to help!

calling any subscript takes care of any sub s within. label-loading will work even if those "innards" aren't explicitly included in the list of labels-to-load.

I was hoping that was the case Sammay, but I wasn't positive so I figured I have to test to check it out. Thanks Sammay.

dontmentionit.
Heh, I secretly did a little test before posting anything

Code: Select all

"_Initialize"
 echo init;
"m1 : 1"
 echo m1;
 sub _2;
"m2 : _2"
 echo m2;

Code: Select all

::load scratch, '_Initialize;1';load scratch, '1'; 

[/size]
ed. I supplied captions instead of labels...

[klownboy]

So...I guess what you're saying is in part....if you specify a caption as well as a label, and if they're different as you have in your test script, you have to refer to the "label' when using SC sub or load (e.g., ::load scratch, '_Initialize;1'; works). As far as the echo in "_Initialize", this topic has come up before. If you run scratch by itself with no labels, "init" is echoed, but when you run the list of labels, the first being "_Initialize", the echo for "init" is not performed. Stepping through it you can see "_Initialize" is bypassed. Is that a bug? It doesn't seem like it would be expected behavior. I know from the help and real world use the "_Initialize" is bypassed when you specifically called out a label, but in this case you're calling out "_Initialize" specifically so it does seem odd. However, when you run in the AB "::load scratch, '_Initialize';" init is echoed.

[bdeshi]

Hm, didn't notice that. Yes, that's odd.

[TheQwerty]

but when you run the list of labels, the first being "_Initialize", the echo for "init" is not performed.

Keep in mind you are running the list of labels. You're more specifically saying display a menu consisting of these items.

In other words it is not going to run '_Initialize' and then '1', but show a menu consisting of '_Initialize' and '1'.
So why doesn't '_Initialize' show? That goes back to the difference between a script being hidden via caption vs label.

Whether XY should run '_Initialize' as part of that load is a bit of gray area in the documentation.
But I believe the original rule of thumb was '_Initialize' is only run when no labels are specified.

[klownboy]

Thanks TheQwerty, I remember reading and bookmarking that link you referred to back at the time. Don't you think "_Initialize" should be a special case? That post doesn't distinguish any differences there may be in the case of "_Initialize and "_Terminate". I know "_Initialize" will not be run if you spell out a label in the script resource as it is when you load the entire resource. You'd think though that if "_Initialize" is specifically called out it in a load list of label / captions situation, it would be run regardless of the other labels or captions specified or how they're specified. It doesn't seem right to me especially considering "_Initialize" is supposed to have special significance concerning the running of a script resource. It seems in this case it takes on the same rules, and I use that term loosely, that any other hidden label or I should I say caption have.

[TheQwerty]

You'd think though that if "_Initialize" is specifically called out it in a load list of label / captions situation, it would be run regardless of the other labels or captions specified or how they're specified.

No... I disagree with that and placing '_Initialize' in the list of labels is just an odd thing to do.

I could understand some reasoning in running '_Initialize' if the list of labels results in showing multiple menu items, but I think even this needs some thought - as this actually makes the rules more complicated and difficult to comprehend.

If anything I would consider it a bug that Load $res, '_Initialize;otherScript'; shows a menu consisting of a single item instead of just executing that item.


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.

[Stef123]

Whew - this turned out more challenging than I expected. When I ran into a sub-script w/o label, I tried its caption. But that doesn't work. So I provided a label myself by modifying the script. Then reconsidered - this seemed like too much maintenance to keep up with changes. Ken does a great job adapting the script to an ever-changing environment and user requests, every new version will break my CTB. Back to reading the help file again and came up with "#4" to reference what I need by index. This promises a more durable solution. Better suggestions I may have overlooked?

Picked up a few things along the way. Underscore hide-outs (great link TheQwerty) and the somber realization that I cannot do without the 2 colons. "load" alone will bring up some stuff but w/o captions. Help doesn't yield explanations about the colon-thing, when to prefix and when not.

I would consider it a bug that Load $res, '_Initialize;otherScript'; shows a menu consisting of a single item instead of just executing that item.

Very good point, really. It made me wonder - how would I call from my CTB if I needed the "_Initialize" part? ATM it pops up a menu with a single item that I failed to click until I realized it's not some kind of mouse-over hint but an actual command I have to trigger. Very easy to miss.

[bdeshi]

it appears _Init cannot be triggered as I'd suggested. Fortunately other features of TM.xys work well without _Initialize as long as it's effects are effective (ie, Create all thumbs at once is on)
So in this case, you're better off skipping _initialize from the loads, overriding the single menu popup.


ed.

Help doesn't yield explanations about the colon-thing, when to prefix and when not.

"Scripts, when prefixed with "::" (double-colon), can be executed directly (i.e. quickly) through any interface in XYplorer that can process locations: Address Bar, Go To, Favorites, Catalog etc. This gives you a lot of choices for usage and storage of scripts."
In general where there's a singleline textbox for locations/files, prefixing :: is needed.
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)