Expanding "CEA_ListRightClickOnWhite=XXX" Tweak

[nerdweed]

Just created a single UDC to use the tweak. Time to implement Qwerty's script in it

Code: Select all

"CEA"
	if (get("FocusedControl") == "T") {
		status "Hi" ;
	} else {
		status "Hello" ;
	}

[PeterH]

Seems I'm with TheQwerty here: instead of changing some XY parameters (like CEA_*RightClickOnWhite_Script) by a script you can set some permanent variable, and the currently associated script can read it and react accordingly. For example it can call some other script - "as if" CEA_*RightClickOnWhite_Script (or whatever) would have been changed.

This really seems not to be more difficult than changing XY settings (by script), and can be done with already existing scripting functions.

[klownboy]

I tend to agree now with what you're saying TheQwerty and PeterH.

I found it interesting though that you can set "CEA_TreeRightClickOnWhite_Script= to a perm variable, for example

Code: Select all

CEA_TreeRightClickOnWhite_Script=::Load "$TreeRightClickOnWhite";

and then in a script establish the variable like so...

Code: Select all

  perm $TreeRightClickOnWhite="<xyscripts>\XYmenu.xys";   //  to load a menu on right click on white click
or in the same or different script say...
  perm $TreeRightClickOnWhite="<xyscripts>\vTB.xys";   //to load a different menu on right click

and change the the variable in the script or in a different script and load a different script on Right Click on White. So in a way you can get the best of both worlds, load scripts of different types via menu AND change the scripts of themselves. No save is required.

Don were you aware you can use a variable assignment for the script in XY's ini file? Kind of cool whether it's logical, useful or not. But, there might be a reason with in a script to change the variable and consequently the actions depending on what you're trying to accomplish.

Thanks,
Ken

[PeterH]

Hm - with the permanent variable: I wouldn't have thought about it. But now as you say: this is a one line mini-script, and executed as such. And executing it variables are resolved.

By the way: in your example you specify ="<xyscripts>\XYmenu.xys";
I think you just can reduce it to ="XYmenu.xys";
This is automatically relative to XY script directory. (Didn't test for this use case )

And some tip: for scripts I will not to start manually I have a subfolder to the script folder, named system. For this I write ="system\XYmenu.xys";
(Better selection of manually executed scripts in a shorter list...)

[TheQwerty]

So in a way you can get the best of both worlds

I still don't see anything good from this other world that you want to live in, but feel free to make things as complicated as you want.

[admin]

Uhm, I'm reading this but no time to respond. One day CEA will come to the UI...

[klownboy]

So in a way you can get the best of both worlds

I still don't see anything good from this other world that you want to live in, but feel free to make things as complicated as you want.

Who knows what kind of world we live in? Again, maybe a bad choice of words and I may never see a reason to use or change the referenced script in a script, but I think it was cool that you could change it by that means regardless.

[TheQwerty]

Don, can we see the existing tweak options more easily accessible via scripting via some new Misc. commands?

Miscellaneous | List | Edit Menu
Miscellaneous | List | Folder Shell Menu
Miscellaneous | List | Folder Shell Menu (Reserved/Extension-Only Version)
Miscellaneous | Various | Drives+Special

Not sure the second-level categories make sense (Various & List), so feel free to change them as you like.

*bump*

Refresher: I'd like to see new commands (above) to display the menus which can be displayed for each CEA_ListRightClickOnWhite value. Thus making it very easy to have all of the options available to the user by using a script (6).

Any chance on this Don?