Environment Variable

[johnboy691]

Because I have such large macros I am running short on string variables. I am going to use environmental variables but am wondering how to manipulate the data in the environmental variable once it is established. I want to copy portions of it, maybe delete portions of it, perhaps append to it, etc. etc. But, in my modify variable command so many times I can't put the name of the environmental variable in because it has a drop down for the T variables. Has anyone used environmental variables and found "tricks" in manipulating them. Thanks for any help.

[rberq]

Could you set aside a single Tx variable and always get from / save to that variable? You might be able to write two callable macros to do the save and retreive, rather than duplicated the coding in many different places.

 

For that matter, instead of setting aside a Tx variable, maybe you could reserve three unique environment variable names solely for use by a callable "utility" macro. In the first env var you would place the name of the env var that you want to store or retrieve. In the second you would place a (S)ave or ®etrieve indicator. In the third you would place the data to be saved. Then call your utility macro. Or in the case of retrieving, you would call the utility macro with the ® code and expect to find the retrieved data in the third env var upon return from the call. The called utility macro would no doubt need to use some Tx variables in the course of its work, but it could store their initial contents in still other reserved env vars and restore their contents just before returning to the caller.

[johnboy691]

Thanks rberg for your ideas. It worked great.

 

Now, taking this further I found there isn't a "simple" way for moving environmental variables for the purpose of copying part, putting to a integer or decimal variable. So I had to do some thinking. I copy the initial value by putting it in a T variable. I then store it to an environmental variable for safe keeping within the macro. 20,000 lines latter when I need to input the text into the program, walla, text type and it's there.

 

But if it was a number, my program won't except a text type of a T variable in the number field...so I had find a way to make the environmental variable back to a Decimal variable. Below is what I ended up doing. Works great! I'm sure there is probably an easier way...but I get it done. This was one of the reasons I had never used environmental variables to much in the past. Now I can go forever...or at least as much as my system will let me. Just wanted to share.

 

<TVAR2:01:03:><TMVAR2:19:01:00:000:000:TEST1><TEXTTYPE:<ALTD><TAB><ALTU>><WAITPB><TVAR2:05:01:1><TMVAR2:21:05:00:000:000:1%TEST1%><TMVAR2:06:05:05:000:000:><ROUND:5:2><TEXTTYPE:%D5%>

[rberq]

Thanks for the feedback, John. I have never run out of variables, but I have wondered what I would do when it does occur. Using environment variables effectively provides storage without limits.

 

P.S. Do you know if there is such a thing as a "global" environment variable within Windows? The one time I tried to use env vars was to pass information from a macro to a VB program. But the variables seemed to be local to the application that created them, so VB could not see what ME had stored and vice versa.

[paul]

Now I can go forever...or at least as much as my system will let me

You need to be careful. My understanding is that the space reserved for EVs is limited.

 

Another, possibly better, solution is to reserve an area in the registry and use that. This is the solution we use in our PGM Library which allows a 16-deep stack, each containing independent sets of t1-t99, N1-N99, etc. And, of course, the registry value names can be anything you like, not limited to ME variable names.

[johnboy691]

Thanks Paul;

You are absolutely correct. I had read about this limitation before I started working on my environment variables. So I went to google and found this...

 

" The maximum length of the combined system and user-defined path for an environment variable is 1,023 characters, excluding the "path=" part of either. The system path is limited to a maximum length of 1,023 characters. The user-defined path is limited to a maximum length of 511 characters. When a user-defined path is combined with a system path, the user-defined path is limited to 1,023 characters minus the system path. If the system path uses the total allocated environment space, the user-defined path may be truncated. In this case, you may experience the problem that is mentioned in the "Symptoms" section. Note These path length limits for environment variables are also true for Microsoft Windows XP and Microsoft Windows Server 2003. ""

 

For my use I use up to 234 environment variables in one macro that capture a total of about 20% being 2 characthers and 80% being 5 to 9 charachters each. So far I have not run into any space limitation problems causing truncated information when all environment variables are populated with data.

 

I also clear each environment variable at the end of my macro so only the environment name is still in the system, just with no data in it.

 

Using the registry would be my first choice, except in my company, the great Gawd of our IT Department has decided employees should not have access to the registry. We've tried for over two years to get this changed with no luck. So until...we can only keep working with the tolls at hand.

 

Hope this information is helpful to others.

[paul]

the great Gawd of our IT Department has decided employees should not have access to the registry. We've tried for over two years to get this changed with no luck.

IMHO, most IT departments should be consigned to the rubbish tip (I know what I'm talking about since I currently work for one!).

 

Perhaps you could use a file instead, populated with value pairs, e.g.

T1 = abc

T2 =

N1 = 456

 

Even better, if you can segment your code so that each discrete module has a separate callable macro, then each of these macros can use their own set of variables. Each time you call the macro that loads your variables, you increase the level which could be reflected in the filename you use. And once you've finished with a particular level, you call the unload macro to decrease the level, similar to the way a stack works.

 

Clear as mud? <g>

[ejs]

P.S. Do you know if there is such a thing as a "global" environment variable within Windows? The one time I tried to use env vars was to pass information from a macro to a VB program. But the variables seemed to be local to the application that created them, so VB could not see what ME had stored and vice versa.

 

As far as I could determine, the environment variables created by macro express are only accessible to macro express (and only until you quit or restart macro express, at which time all the custom environmental variables are cleared).

 

The best way I found for exchanging information between macro express and other programs is either to use an INI file or text file, or (in some cases where Macro Express is calling the other program or vice versa) to embed the information into the command line. The registry could be used as well, but then you would need routines in your other program for reading/writing the registry.