Variables in Multiple Macros

[Amerifax-Bob]

When you create variables in one Macro, can you call that Macro with another Macro and use the variables associated or created in the first?

 

Please see If it was ease we would not need Macro Exoress

 

Would this be making the variables Global? If they are Global are they always on?

 

Thanks for any help.

 

Bob

[Cory]

Yes you can.

..........................................

If you want the variables not to share define the variable as local. Click here for my write-up including some visuals on how global and local variables work.

[Amerifax-Bob]

Thanks Cory. That is exactly what I was looking for (your write-up). Sometimes that makes it so much easier to understand.

 

Bob

[rberq]

Thanks from another Bob for your writeup, Cory. But, another question: In ME3 the standard variables could, in effect, be made global by using SAVE ALL VARIABLES just before exiting each macro, and RESTORE ALL VARIABLES at the beginning of each macro. Does the same hold true for ME Pro?

[Cory]

Avoid Save All Variables.

..........................................

We had a discussion in here recently on that topic and the upshot is that you should generally avoid Save All Variables. Global variables and other methods are far better and there are some problems with it. In our discussion several arguments were offered but IMHO there were only a few esoteric cases where it was useful in MEP. As I see it the command is only present for reverse compatibility.

[rberq]

Avoid Save All Variables.

..........................................

We had a discussion in here recently on that topic and the upshot is that you should generally avoid Save All Variables. Global variables and other methods are far better and there are some problems with it. In our discussion several arguments were offered but IMHO there were only a few esoteric cases where it was useful in MEP. As I see it the command is only present for reverse compatibility.

Can you point me to the discussion of which you speak?

I have a slew of macros which run based on window titles. They must pass quite a number of variables among themselves. Since they are not called by one another, they can not use global variables (which, as you pointed out, are not really global). Short of storing the data in environment variables or in the registry, I don't know an alternative to the Save All and Restore All method. I'm all ears, though, if someone can tell me a better technique.

[paul]

Avoid Save All Variables.

..........................................

We had a discussion in here recently on that topic and the upshot is that you should generally avoid Save All Variables. Global variables and other methods are far better and there are some problems with it. In our discussion several arguments were offered but IMHO there were only a few esoteric cases where it was useful in MEP. As I see it the command is only present for reverse compatibility.

I beg to differ.

 

1) Consider a macro called M1, and a series of macros called MSub1, MSub2, .. MSubn, where M1 calls all the MSubn macros. Any variables declared in M1 are, unless specifically excluded, available to MSub1, MSub2, etc.

 

2) If MSubn macros are run other than as called macros from M1, then M1's variables are not available to any MSubn macros.

 

3) Now consider MSUb1, where a string variable %tMyVar% is declared and initialized with "Created by MSub1". If MSub1 now issues a Variable Save All command, then any macro from now on that does a Variable Restore All command will have access to %tMyVar%, and its value will be "Created by MSub1". This will always be true until some macro clears this variable and then does a Variable Save All.

 

4) If you wish to run macros with the MeProc.exe program and pass in parameters, then you are forced to use the Variable Restore All command in order to access the passed-in parameters, as in:

MeProc /AMSub1 /VtMyVar:Not created by MSub1

 

Having said all that, the current release of MEP has a problem where the Variable Restore All command is incredibly slow, taking several seconds instead of the expected fraction of a second.

[rberq]

Having said all that, the current release of MEP has a problem where the Variable Restore All command is incredibly slow, taking several seconds instead of the expected fraction of a second.

Ouch! I really really need to go to MEP, for its ability to lock mouse and keyboard. But I use Save All and Restore All many many times across several dozen macros, so the excessive time will be a problem. I have written logic for ME3 to stash Tx, Dx, and Nx values into environment variables, and retrieve them again, and it's very fast but it's not dynamic -- that is, it won't automatically pick up any new variables that I might define in MEP. Ideas, anyone?

[Rustywinger]

Ouch! I really really need to go to MEP, for its ability to lock mouse and keyboard. But I use Save All and Restore All many many times across several dozen macros

 

 

Bob, I am in the exact same boat. I have hundreds of Macros running Save and Restore Vars. Currently they are all in ME3 environment being used among the front line workers. I too, would love to get the peripherals control added to the equation to strengthen the effectiveness of the macros, but the delay involved in loading the vars is simply unacceptable.

 

I really don't see why I should make the formidable investment of rewriting all my macros to accommodate what is obviously a programming flaw which had no adverse effects in previous versions of ME, in fact earlier versions of MEP did not have this issue. I should just be able to convert my legacy files, add in the new functionality (KB/Mouse locks) and go about my business.

[Cory]

You are absolutely right Rusty.

.................................

I always give you guys a bad time about using variable save and restore because I feel it’s an inferior method and you are not using it for its designed intent (using a hammer to drive a screw) but you are correct in that it should work. Especially as you pointed out to support ME3 conversions. But I do feel that it’s a fluke that it does work the way you use it and highly recommend you try to migrate away from it.

[Rustywinger]

You are absolutely right Rusty.

.................................

I always give you guys a bad time about using variable save and restore because I feel it’s an inferior method and you are not using it for its designed intent (using a hammer to drive a screw) but you are correct in that it should work. Especially as you pointed out to support ME3 conversions. But I do feel that it’s a fluke that it does work the way you use it and highly recommend you try to migrate away from it.

 

I wouldn't use hammer and screw as an analogy, at most it is using the incorrect size screwdriver for the screw head. This method works and will work flawlessly (without damaging the wood even!) for what it is being used for, simply passing data from one macro instance to another. I agree that writing to files is a far more stable way to be doing this and this is what I do in the newer macros I write, however this issue is going to come up again and again as long as people have substantial libraries of legacy macros that cannot be easily updated.

 

Also, I don't think there is anything stopping the good folks at Insight from simply converting the process from dynamic to static. Seriously, that would have to be a dead easy modification to make to the process.

[Cory]

Let me clarify.

.......................................................................

When I use the hammer and screw analogy I mean when people run a macro and the last command is Variable Save and then run the macro again in 5 minutes with the first command as Variable Restore as a way to remember variables from one run to the next.... That’s what I think is an unintended usage. IE there are serious shortcomings like what if you want to run another macro in between? If in the middle of the macro one uses save and restore around a Macro Run that is an intended use for ME3 and not what I am talking about.

 

As for using Variable Save/Restore around a Macro Run in MEP my analogy would be taking your normally aspirated race car and going from class 3 to class 2 where turbo charging is allowed and not adding a turbo. It’s not ideal but it should work. And given the cost of retrofitting a turbo to a chassis and engine designed for regular breathing might be costly and time consuming. However I think you would be a fool to build a brand new class 2 car from scratch and not turbo charging just because you didn’t want to take the time to learn about turbo charging. How's that for a fun analogy?

 

BTW I rarely use files to save settings and prefer to do it like most Windows programs do and that is to use the registry. The only INI files I use are settings for distributed macros and those are saved with the macro folder on the network where everyone uses the same INI and MEX file. But even then the individual user preferences are saved locally in the registry so they can all personalize their macro experience.

[Rustywinger]

Let me clarify.

.......................................................................

When I use the hammer and screw analogy I mean when people run a macro and the last command is Variable Save and then run the macro again in 5 minutes with the first command as Variable Restore as a way to remember variables from one run to the next.... That’s what I think is an unintended usage. IE there are serious shortcomings like what if you want to run another macro in between? If in the middle of the macro one uses save and restore around a Macro Run that is an intended use for ME3 and not what I am talking about.

 

Well, I don't speak for others, but I track what all the variables contain (remember this was all designed in ME3) in a reference spreadsheet. There is a mix of variables that are always used for the same purpose and a mix of variables that are random from macro to macro. A variable save can contain X active items which can be used by my other macros at any time. They are all designed to work within the parameters of the reference spreadsheet.

 

For example, in addition to actual integer content, I use the N variables as flags that allow the current macro to know what's up. I use the T values to share data strings that are common between tasks. The process that takes up the bulk of my macros could accurately be described as brackets, there is one set of macros that begin the process, set conditions and flags based on dynamic interaction, then stops entirely as the data entry clerk runs utility macros based on the task at hand. When done, the closing bracket macro cleans everything up, saving this, filing that, recording those. There are hundreds of automatic tasks involved in the brackets as well as the 'semi-automatic' tasks between which all draw from the current pool of data saved in the variables.

 

Maybe it's rudimentary (or Rube-imentary) and lacking in a turbo, but it's all working just fine for us.

[Rustywinger]

And I'm a bit miffed nobody's throwing me a party for becoming "Advanced" lol

[Cory]

Wow, what a pain! Even in ME3 I found it much easier to save things like that in the registry. Don't you run out of variables pretty quickly? I too would keep track of variable and what they were for in the notes but each macro had a fresh set. And now we have named global/local variables so that's all just a bad dream now.

[Cory]

Does this mean I have to respect you more now? Naw, seriously congrats. It's good to have contributing members that stick around. But I didn't get any congratulations when I became expert either. Or when I busted 1000. But then again I didn't ask for it!

[rberq]

I didn't get a party either when I became Advanced. I don't know the criteria, but I suspect it's just based on number of postings, a recognition of persistence rather than expertise. So I haven't let it go to my head.

[Rustywinger]

I didn't get a party either when I became Advanced. I don't know the criteria, but I suspect it's just based on number of postings, a recognition of persistence rather than expertise. So I haven't let it go to my head.

 

Bob, I was kidding... Like I could be considered advanced. There are actually two advanced:

 

Advanced SNAFU fixer

Advanced SNAFU creator

 

I generally fit in the bottom one.

 

Eventually, I will be an Expert Snafu creator, and then who knows, perhaps I will be stupid enough to become a Master.

 

Where is your god now?

 

;-)

[paul]

I really don't see why I should make the formidable investment of rewriting all my macros to accommodate what is obviously a programming flaw which had no adverse effects in previous versions of ME, in fact earlier versions of MEP did not have this issue. I should just be able to convert my legacy files, add in the new functionality (KB/Mouse locks) and go about my business.

I flinch!

 

Surely you can understand that in ME3 the number and names of variables are known at all times; 99 text variables %T1%-%T99%, 99 integer variables %N1%-%N99%, 99 decimal variables %D1%-%D99%. What could be easier?

 

In MEP there is no limit to either the number of variables or the names, and there are even scalar and array variables to add to the mix. So we can have %T[1]%-%T[47]%, %MyTextVar1%, %MyTextVar2[1]%-%MyTextVar2[500]%, %MyIntVar%, etc. ad infinitum.

How MEP can even manage to cope with Variable Save and Variable Restore commands is almost beyond comprehension. For anyone to say "I really don't see why I should make the formidable investment ...." and "I should just be able to convert my legacy files..." is plainly ridiculous!

[kevin]

How MEP can even manage to cope with Variable Save and Variable Restore commands is almost beyond comprehension.

It turns out to be more difficult than we expected.

 

"I really don't see why I should make the formidable investment ...." "I should just be able to convert my legacy files..."

We are doing everything we can to fix the problems with the Variable Restore command.

 

Just don't try it with the (released but not yet announced) Macro Express Pro v 4.1.1.1. We are working on another issue with Variable Restore.

[Rustywinger]

I flinch!

Oh relax!

 

For the most part the fine people at Insight have done this very well, I have had no issues at all with the conversion itself of the legacy files.

 

The issues I did have were with macro timing, not variables.

 

There was also the speed of loading the saved variables, which 4.1.1.1 appears to have addressed well.

 

And then there is the new issue of the crash when restoring vars that have not previously been saved. But an easy workaround fixes that for me.

 

All in all, this has worked very well considering the huge amount of Macros I was able to simply convert and run in the testing environment. I have not yet deployed anything and likely won't for awhile yet as the processes our offices use work just fine for now in ME3. I'm really not in a hurry to have an angry mob after me! :-)

[Rustywinger]

Surely you can understand that in ME3 the number and names of variables are known at all times; 99 text variables %T1%-%T99%, 99 integer variables %N1%-%N99%, 99 decimal variables %D1%-%D99%. What could be easier?

 

?? Now this is confusing... I could have sworn for a variable value created in one macro to be available to another, it needed to be saved by one (by whatever your favorite means) and loaded by macros used later. As far as I know, ME variables do not stick around once a macro stops without saving them.

 

Or perhaps you are talking about something else?

[terrypin]

Flies are never pretty but that last one is uglier than most

 

Quite like the second one. Probably me but the WB looks quite different between the first two?

 

Eh?

 

Wild guess, but was this meant for a photography forum? ( 'WB' = white balance??)

 

Seem to recall another bizarre post by same person a while ago.

 

--

Terry, East Grinstead, UK

[Cory]

Just report these to the mod when you see them. Been several lately. At first they looked like mis-posts but given we had two from the same dude today with exclusive questions in each leads me to believe there's something fishy going on here.