Defining Your Own Permanent Environmental Variable

[Cory]

I posted a while back on using CRLF and TAB and several people shared how to create these variables. Then Randall pointed out how he liked to save them as and environmental var (lets call it an EV) instead. I really didn’t see the big advantage but I do like the idea of using them as I could create several standard ones and not be limited to the TXX problem where I always have to step around them and keep them unique. Problem is they to evaporate per session. Well I figured out a killer solution! Well at least I’m happy with myself.

 

The command in ME only writes to the user EV but if you write to the registry you can create system EV’s. Simply write anything to the key below and that’s it! The downside is that you may have to reboot.

 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\

 

Text Box Display: Test of Tab and CRLF from perm environmental

<REM2:Set CR><ASCIIC:95:1:13><ASCIIC:96:1:10><TVAR2:95:01:%T95%%T96%><REM2:Set CR><REM2:Set 
TAB><ASCIIC:94:1:9><REM2:Set TAB><REGWSTR:95:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\CRLF><REGWSTR:94:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment\TAB>

 

<TBOX4:T:1:CenterCenter000278000200:000:Test of Tab and CRLF from perm environmental123%TAB%456%CRLF%789>

 

Just thougth I would share, hope someon finds it of use.

[cyberchief]

Well... this brings to mind a question that I have been wanting to ask... I could probably test it myself and find the answer... but I am sure that someone here can answer quickly without me having to type unneeded code. And... again... maybe this has already been answered...

 

When using the variable save command... and variable restore command... if I set an env variable after saving... will that, also, be overwritten on the restore command? If yes... then I can see use of the Perm Env as above... if not, how do you clear Env variables after using them?

[Cory]

No it will not. VAR save and RESTORE are for ME vars. Otherwise things like your system directory path would dissapear! So in my way of thinking this gives us two sets of variables and a way to portage around the Variable Save and Restore commands. This will be very cool for calling subroutines where we want to set everythign back as it was except the results of the one thing the subroutine did. Also it's just handy for variables that don't often change like user name, email address and other such things. But for the CRLF and TAB values it's very cool. Also it's nice to have vars like in programming where they actualy mean something. "%TAB% or %CRLF% is much more intuitive than %T95% and %T94%.

[cyberchief]

Thanks Cory... but that still leaves my last question unresolved... if the Env Variable is not overwritten... how do you clear them when the routine is finished... or, in my case, loops and runs again with a whole new routine?

[kevin]

The environment variables are cleared when the environment in which they are created disappears. In other words, when you set an environment variable from within Macro Express, it stays until Macro Express is terminated and reloaded.

 

To 'clear' an environment variable without reloading Macro Express you will need to set it to an empty value.

 

This discussion has just raised a warning flag for me.

 

It is not recommended that you run Macro Express 24x7. It needs to be reloaded on occaision. The reason for this is that when certain macro commands finish, Macro Express tells Windows to unload the memory used by the macro command. However, Windows does not always unload the memory or, if it unloads it, there may be a few bytes that Windows still considers 'used'. Under normal operations no one notices these stray bytes. We're talking about something like 16 bytes every time a certain macro command runs. However, over time, these stray bytes have a tendency to add up.

 

For example, one customer has a macro that runs every second. If this is left running 24 hours a day 7 days a week then eventually the 16 bytes used each time the macro runs add up to a significant amount of memory.

 

Reloading Macro Express corrects this. There is a macro command to do this for you. If you leave your computer on all the time, we recommend that you periodically run the Restart Macro Express command.

 

Now, you are probably wondering why I brought this up in a discussion about the environment variables. Well, if you expect the environment variables to exist all the time, they will ... until Macro Express is restarted.

 

Unless you use Corey's suggestion. If you do then the environment variables will exist even after Macro Express is restarted. To understand why this is so requires another long explanation. I'll do that in a separate post.

 

Keep this in mind as you use environment variables.

[kevin]

If you already understand how Windows handles environment variables then you do not need to read this post.

 

All of the environment variables that exist when a process starts are copied to that process. However, when a process ends, the environment variables, and their values, that were changed in the process are not passes back to the parent process.

 

You are probably saying: What? Huh? I'm confused.

 

Okay, when Windows starts it creates a global set of environment variables. These include things like PATH, APPDATA, COMPUTERNAME, WINDIR, SYSTEMROOT, etc.

 

Each process (application, program, .dll, etc.) that Windows loads receives a copy of these environment variables.

 

If Macro Express is used to change the environment variables then any program that is launched from Macro Express will receive those environment variables.

 

Then, suppose the program launched from Macro Express changes the environment variables. The new environment variables will be available to that program but not to Macro Express or to Windows. When that program closes, all of its environment variables are lost.

 

And, when Macro Express closes, all of its environment variables are lost.

 

This is not as easy to describe as I thought it would be. I hope you understand.

[bobchernow]

Not trying to be a spoil sport but if you are going to use the registry to create these Permanant EV's and you plan on sharing or distributing your macros you should make sure that you macro code includes the Registry initialization code or provide a "Setup" macro that creates it. Just a word of caution

[kevin]

Another word of warning: Not all users can write to the HKLM area of the registry. So, even if you do create a registry initialization or setup macro, it will not work for non-administrator users.

[randallc]

Hi, Cory,

 

Sounds fascinating.

I had already been thinking more about this since you wrote before. I am stimulted to compromise, and include the setting up of EV like CRLF in a "scheduled startup" macro that runs each time ME starts.

 

This solves some of the problems above, avoids the registry, but still means you'd need to either;

1. run the startup macro as part of every library using your routines ;

or

2. add them to the beginning of any macro not run with your library.

Any thoughts?

Randall

[floyd]

When Joe and Paul first begin putting together the PGM Functions Library, environment variables were used. As it turned out, they did not fit the requirements of being able to save and restore multiple layers of variables. Why is this important? Well, If you are planning on creating reusable macros, then anything that happens within those macros must be entirely independent of anything outside of them.

 

A user must be able to call these little black boxes at any point in a macro application (even recursively) without changing, or affecting in any manner, the state of variables in the caller (parent) macro. And what about a situation where the user calls a macro, which calls another macro, and in turn calls another one, and then another? Where are we now, 5 or 6 level deep into the macro application? Environment variables cannot handle that kind of load.

 

Beginning on page 272 of the Macro Express Explained book, there is a section that explains how to properly handle variables within the multiple layers of cascading macros. This is also explained in the PGM Functions Library manual beginning on page 72.