User Environmental Variable Refresh

[klownboy]

Hi Don, You stated here http://www.xyplorer.com/xyfc/viewtopic. ... &start=150 that it would create too many side effects if you were to code perm variables such that they displayed on a menu. Based on that, I've been revisiting environmental variables. I didn't really expect to have any luck, but I was able to create an environmental via Control Panel-System-Advanced System Settings-Environmental Variables, and have it display in a menu. Note: The variable also shows up under Help-Environmental Variables. I say I didn't expect to be able to since the help file refers to "valid" environmental variables.

That's all fine and good, but in scripting it probably doesn't do us much good unless we can change the variable on-the-fly. I had some success in changing environmental variables using the built-in Windows command, "setx", http://technet.microsoft.com/en-us/libr ... s.10).aspx, but I've noticed that changes are not reflected until I restart XYplorer (e.g., ::run "cmd /c /q set VAR= & setx VAR [pizza]",,0,0; ). Setx will set a variable pernamently until deleted / changed as opposed to using the "set" command where the env variable is only applicable for the current console session. I tried refreshing the environmental cache (View-Caches-Refresh Env Caches (also Command ID #505), but it doesn't seem to refresh either the local "user" environmental variable or a "system" type variable. Yet, they do refresh and appear on the Help-Environmental list when you reload XY. Could you possibly look into that and tweak it such that the "Refresh Environmental variables" command refreshes either a "user" designated env variable or "system" variable? It would be a worthwhile substitute for the perm variable being able to display them on a menu.
Thanks,
Ken

[admin]

Oh man, I give up, you get your perms-in-script-captions...

[klownboy]

Hi Don, I should have been a used car salesman! Thanks once again.
I am having a strange issue with that change though. The perm variable displays properly in some situations but not in others. It seems that when the menu line containing the perm variable you want to display is over so many characters the menu line returns a "1" and that's it. Try this simple test or something similar: [I assigned this simple script to a CTB to test what was going on ]

Code: Select all

   perm $TB; $TB = "[with TB]";

"$TB";
"Wallpaper $TB";
"Pictures Icons $TB";
"Pictures and Icons $TB";
"Pictures && Icons $TB";
"Pictures and Wallpaper $TB"
"Pictures and Wallpaper $TB";

The first 3 lines display as they should the last four lines do not. They display a "1".
Thanks,
Ken

[admin]

Oh yes, mea stupidity. Fix comes.

[klownboy]

Thanks Don,
When first testing the change, I had an "environmental" variable still in force, but I then deleted it and was scratching my head when the "1" displayed.

By the way, back on my first post, I was curious, is there some reason why the "Refresh Environmental variables" doesn't refresh a variable put in via the control panel or using the "setx" command, but a restart of XY did? Something different called to refresh? Once restated, the variable also shows in the Help-Environmental Variables list.
Thanks again,
Ken

[admin]

By the way, back on my first post, I was curious, is there some reason why the "Refresh Environmental variables" doesn't refresh a variable put in via the control panel or using the "setx" command, but a restart of XY did? Something different called to refresh? Once restated, the variable also shows in the Help-Environmental Variables list.
Thanks again,
Ken

I checked that quickly and did not see a reason why. Then I gave up.

[PeterH]

@klownboy: congratulations

I found it interesting to see
perm [with TB]; [with TB] = "[with TB]";
(You know what I mean? )

To tell the truth: I found it multiple interesting - as I wouldn't have expected exactly this
1) that a non-label script in a multi-label script file is shown this way in the selection dialog
2) that $TB is replaced in perm $TB; and in $TB = ...;

Is there a reason why the first line has no label? I've tested it with
"Main" perm $TB; $TB = "[with TB]";
and think it looks better this way?

[klownboy]

Hi Don thanks. v11.90.0207 works great!

Hey PeterH, Yes, putting "Main" in front of the variable settings does look much better. Realize though, it wasn't a real script, I just wanted to show the problem which is now fixed. Either way though, it's too bad it won't auto-execute. Maybe a later request (an auto-execute section)

It is a little strange and unexpected that the variable displays that way, but I suppose it makes sense. This is behind the scene so to speak, it's all fine as long as setting ,changing, and unsetting the perm variable work alright.

I've ran a couple of tests, it doesn't appear we need to use the "unset" command prior to giving the same variable a different value.

To get my menu label changes working properly (i.e., to display differently depending on whether I left clicked or right clicked), I used a "_leftclick" label on the left click command for the CTB to set (actually change) the permanent variable in the script based on <get trigger> left click and the right click of the CTB would have the "normal" Perm variable. So the perm variable is changed if I left click and the same if I right click. Of course I have to reset it at the end of the script. The problem I have is resettng the variable if I cancel out of the script (i.e., hit esc or click outside the menu) and not perform one of the menu items. Is there any way to perform an action like that on cancel? I'm looking at "end" and "break" but I'm not sure if it will do it.
Thanks,
Ken

[admin]

I'll think about it. It might add an Initialize and a Terminate event, 2 optional scripts that are auto-called on loading and ending a multiscript resource.

[PeterH]

I'll think about it. It might add an Initialize and a Terminate event, 2 optional scripts that are auto-called on loading and ending a multiscript resource.

Terminate event - I wouldn't have thought of this - but might make sense!

Just ideas:
- execute those auto-scripts only for non-hidden scripts?
- define a system variable containing the label of the called script
- define a system variable telling the type (hidden/non-hidden) of the called script

Second and/or third might replace the first point - that's more flexible!
I think the 2nd is the most important - using it you can also resolve all other points by logic. The 3rd just helps a bit (substr(<label>, ,1) not necessary).

[klownboy]

Hey Don & PeterH,

I'll think about it. It might add an Initialize and a Terminate event, 2 optional scripts that are auto-called on loading and ending a multiscript resource.

I'm not sure if these new potential buillt-in scripts or functions (Initialize & Terminate) should have anything to do with perm variable, or whether the script was called from another or whether hidden or not. I know we're currently discussing perm variables and calling scripts etc., but why would it have to be so specific? There would be a number of cases where we may want to invoke or initialize statements or to call commands upon terminating a script regardless of the above factors. I haven't been around in the forum too long so maybe I don't have the big picture, but I've seen the idea of initializing and or auto-executing section for commands being kicked around a number of times.
Thanks,
Ken

[PeterH]

I assume that these are scripts possibly contained in the (multi-)script-file you call. (So for different script files(!) you can use different initialization.)

And as of now scripts only can communicate via global or permanent variables. So I think the main use will be with those.

Further I assume the main use will be for preparing / modifying captions displayed in the selection-dialog for the scripts, i.e. for work that has to be done *before* an explicit script is started. (I think this only regards non-hidden scripts?)
For work that can be done *after* a unique script was selected / started I'd very much prefer other means, as:
- the ability to use something as "include", i.e. the ability to execute some lines of "loaded" code in the local scope
- the ability to call subroutines and functions, with use of parameters and eventually (a) return value(s).
These would help here, *and* could be of much more general use, I think.

This were the thought's i had in mind when I wrote my previous comments.
Of course Don often has his own ideas - and might see this from another perspective. (So I said "assume" above. ) Let's wait what he says...

[admin]

Not sure I understood the last two posts, or you understood mine.

My idea in other words: You could add two scripts with special reserved names to a multi-script resource with captions "Initialize" and "Terminate". If XY would find a script called "Initialize" it would auto-call this script on loading the multi-script resource, and analogue with "Terminate".

[PeterH]

Not sure I understood the last two posts, or you understood mine.

My idea in other words: You could add two scripts with special reserved names to a multi-script resource with captions "Initialize" and "Terminate". If XY would find a script called "Initialize" it would auto-call this script on loading the multi-script resource, and analogue with "Terminate".

I think I meant it as you say.

And was talking about what can make sense there - especially defining/setting global/perm variables, especially for use in displaying selection dialog. Isn't it?

[klownboy]

Hey again Don & PeterH,
OK, sounds great! I think I get the drift of what you're saying. So the "Initialize" or "Terminate" reserved script names would be a script within a multi-script resource file that XY would recognize and auto-execute or auto-call as you put it. XY would automatically run them when it detects their presence in the multi-script resource. So I assume they would not need to be called in the multi-script resource using "sub" or "load"? Could they also be a script in itself in a single script file (e.g., initialize.xys) which could be loaded when called from other scripts? Maybe that wouldn't be right because different scripts calling this "initilize" script would haven't different initializing commands to be accomplished.

Most definitely, initilize and terminate would be extremely usefull.

Thanks,
Ken