Passing variables to macros run via Run command

[arekowczarek]

I never really understood how variables are passed from one macro to another macro. I think it's high time I finally do.

 

According to ME help file:

Global Variable

A Global Variable is accessible inside the macro where it is defined and in all other macros called by that macro via the Macro Run command. It is recommended that global variables be defined in the main macro.

For example, suppose you have macros A, B and C and A is the main macro that calls macros B and C via the Macro Run command. After defining a variable named %Address% in macro A both macros B and C can use this variable. Changes made to the value of %Address% in macro B would be available in macros A and B.

 

So here's what I did"

1. I created MACRO A

2. MACRO A sets variable %T[1]% to "A"

3. MACRO A runs MACRO B

4. MACRO B claims that %T[1]%="" (blank, undefined)

 

Why wasn't the value passed to macro B from macro A? What am I missing here?

[terrypin]

I can't reproduce that.

 

Macro A

Variable Set String %T[1]% to "abcd"

Text Box Display: Macro A

Macro Run: Macro B

 

Macro B

Text Box Display: Macro B message

 

The result of running Macro A is two TBDs, both showing 'T[1] = abcd'.

 

I assume you have checkmarked "Make this variable available to macros

called by this macro" in the Properties for T[1]?

 

--

Terry, East Grinstead, UK

[Cory]

http://www.bluepointdesign.com/macros/GlobalLocal/default.htm

Read this

[arekowczarek]

I assume you have checkmarked "Make this variable available to macros

called by this macro" in the Properties for T[1]?

Yes, I did.

 

 

Here are the codes for Macro 1 and Macro 2 I used for testing:

 

Macro 1

<VARIABLE SET STRING Option="\x00" Destination="%T[1]%" Value="ABC" NoEmbeddedVars="FALSE"/>
<TEXT BOX DISPLAY Title="MAC 1" Content="{\\rtf1\\ansi\\ansicpg1250\\deff0\\deflang1045{\\fonttbl{\\f0\\fnil\\fcharset238 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 %T[1]%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/>
<MACRO RUN Use_ID="FALSE" Name="MAC 2" ID="-1" Wait="FALSE"/>

Macro 2

<TEXT BOX DISPLAY Title="MAC 2" Content="{\\rtf1\\ansi\\ansicpg1250\\deff0\\deflang1045{\\fonttbl{\\f0\\fnil\\fcharset238 Tahoma;}{\\f1\\fnil Tahoma;}}\r\n\\viewkind4\\uc1\\pard\\f0\\fs16 %T[1]%\\f1 \r\n\\par }\r\n" Left="Center" Top="Center" Width="278" Height="200" Monitor="0" OnTop="FALSE" Keep_Focus="TRUE" Mode="\x00" Delay="0"/>

 

The TB displayed by the second macro is blank on my machine. Can anyone run the two macros and see if it works for them?

 

Now, I created two separate macros and manually (not copying) inserted exact commands as in macro 1 and macro 2. Result? It works - macro 2 displays the value of T[1].

 

So it looks like in the macros I attached the variables don't receive global scope. But why wouldn't they?

[terrypin]

You need to checkmark this:

 

 

--

Terry, East Grinstead, UK

[arekowczarek]

Agrr, so it was my dumb error! I forgot about this. Works as a charm now, I understand why it didn't before.

Thanks!

[arekowczarek]

Agrr, so it was my dumb error! I forgot about this. Works as a charm now, I understand why it didn't before.

Thanks!

Hmm, on second thoughts, there's one more think I'd like to know. I am assuming that the variable T[1] is not accessible by the second macro, because macro 1 stops and it's variables cease to exist. Why adding 10 seconds delay at the end of macro 1 doesn't solve it (having the box mentioned unmarked)? In such case macro 2 is run while macro's 1 variables are still available, so what's the problem, why macro 2 can't see them?

[paul]

Hmm, on second thoughts, there's one more think I'd like to know. I am assuming that the variable T[1] is not accessible by the second macro, because macro 1 stops and it's variables cease to exist.

Wrong!

- By default, each macro defines 4 array variables of 99 elements called C, D, N and T which are available to called sub-macros. So both macro1 and macro2 "contain" these variables

- Because macro2 is independent (although it's called by macro1, macro1 does not wait for macro2 to complete), its variables come into existence only when it starts (whether as a result of you running it, or being called by macro1)

- If macro2 is called by, say macro3, where macro3 does wait for macro2 to complete, then in this instance macro2's variables first come into existence when macro3 starts and are therefore shared

 

Take a look at this example:

Macro m1

Variable Set String %T[1]% to "qwerty"
Text Box Display: m1 (displays the value of %T[1]%)
Macro Run: m2 (do not wait for m2 to terminate)
Macro Run: m2 (wait for m2 to terminate)

Macro m2

Text Box Display: m2 (displays the value of %T[1]%)

 

Run m1 from the script editor using F8. You will see 3 text boxes containing the value of %T[1]%:

The first box shows qwerty

The second box shows blank

The third box shows qwerty

 

Do you follow?

[arekowczarek]

Wrong!

- By default, each macro defines 4 array variables of 99 elements called C, D, N and T which are available to called sub-macros. So both macro1 and macro2 "contain" these variables

- Because macro2 is independent (although it's called by macro1, macro1 does not wait for macro2 to complete), its variables come into existence only when it starts (whether as a result of you running it, or being called by macro1)

- If macro2 is called by, say macro3, where macro3 does wait for macro2 to complete, then in this instance macro2's variables first come into existence when macro3 starts and are therefore shared

 

Run m1 from the script editor using F8. You will see 3 text boxes containing the value of %T[1]%:

The first box shows qwerty

The second box shows blank

The third box shows qwerty

 

Do you follow?

 

I'm not sure.

So, the choice whether sub-macros will inherit variables from the main macro or not is always made at the start of main macro, depending on whether the main macro will or will not wait for the sub-macros to finish?

I'm really not sure I understand it correctly...

 

Anyway, why running the macro you attached gives different results while running it using F8 from running it the usual way?

[terrypin]

Paul,

 

Well, I am sure: I definitely don't follow!

 

Using your example, Don't wait for m2 to terminate before proceeding [with m1] surely doesn't mean that m2 doesn't even start? And if it starts, then the variable should be available.

 

I'm also unclear why the F8 debug mode should give different results to normal running? I appreciate that it runs slower, and provides interim steps to let you see what command it is about to execute, but I thought that in all other respects it was supposed to be identical? If not, then its value as a debug tool seems to be limited.

 

--

Terry, East Grinstead, UK

[paul]

Anyway, why running the macro you attached gives different results while running it using F8 from running it the usual way?

Using F8 does not produce different results! In this case you need to use F8, otherwise you cannot distinguish between the two calls to m2, since m1 isn't waiting for m2 to finish in one of its calls. I could have inserted logic to handle that but didn't think it was worth the candle!

[paul]

Using your example, Don't wait for m2 to terminate before proceeding [with m1] surely doesn't mean that m2 doesn't even start? And if it starts, then the variable should be available.

"m2 doesn't even start". Why on earth not? If m1 calls m2, of course m2 will start. The purpose of my example is to demonstrate exactly when m2 runs "stand-alone" (i.e. no variable values from the calling macro are available) and when it runs "as part of" m1 (all m1 variable values are available in m2). I thought is was pretty clear.

As I stated elsewhere, I suggested using F8 to run m1 simply to allow you to see m2's messages in the correct sequence. If you run m1 normally, the sequence of m2 messages may appear to be in the wrong order. I was merely trying to make it easier for you to understand. Apparently, I failed!

[terrypin]

Keep your shirt on, Paul!

 

Two out of two respondents so far had not understood your demo, so I think it's reasonable to conclude that at best it wasn't as obvious as you thought! Or as clearly explained as you'd assumed. As you well know, I'm not a programmer, so points that are obvious to you are not necessarily so to me. But I'm always keen to learn!

 

My main hangup was and still is the one I emphasised, and which I still don't think you've answered: when m2 starts, I don't see why it doesn't have access to the variables.

 

You've now introduced a new term, 'stand-alone'. You appear to be saying that the condition 'Don't wait for m2 to terminate before proceeding [with m1]' really also means '...and don't allow m2 access to the variables previously defined with "Make this variable available to macros called by this macro" '.

 

Is that the case? If so, all would become clear. IOW, does the absence of a checkmark against 'Wait for this macro to terminate before proceeding' mean it is what you are now calling a stand-alone macro, which has the very important property (not mentioned in the dialog) of not having access to variables defined in the calling macro? In direct contradiction to the variable settings?

 

--

Terry, East Grinstead, UK

[arekowczarek]

You've now introduced a new term, 'stand-alone'. You appear to be saying that the condition 'Don't wait for m2 to terminate before proceeding [with m1]' really also means '...and don't allow m2 access to the variables previously defined with "Make this variable available to macros called by this macro" '.

 

Is that the case? If so, all would become clear. IOW, does the absence of a checkmark against 'Wait for this macro to terminate before proceeding' mean it is what you are now calling a stand-alone macro, which has the very important property (not mentioned in the dialog) of not having access to variables defined in the calling macro? In direct contradiction to the variable settings?

 

I think macro2 doesn't have access to variables defined in macro1 (if macro1 doesn't wait for macro2) to avoid a situation, in which both macro1 and macro2 operate and have access to same variables. That could cause some mess I guess. But then again, I'm not a programmer either and I also might be looking at it the wrong way.

[paul]

Keep your shirt on, Paul!

Shirt on!

You've now introduced a new term, 'stand-alone'. You appear to be saying that the condition 'Don't wait for m2 to terminate before proceeding [with m1]' really also means '...and don't allow m2 access to the variables previously defined with "Make this variable available to macros called by this macro" '.

 

Is that the case? If so, all would become clear. IOW, does the absence of a checkmark against 'Wait for this macro to terminate before proceeding' mean it is what you are now calling a stand-alone macro, which has the very important property (not mentioned in the dialog) of not having access to variables defined in the calling macro? In direct contradiction to the variable settings?

Bingo! The "don't wait" setting indeed appears to mean that the called macro has no access to existing variables. Insight could certainly have used better wording for this, but there you are.

[terrypin]

OK, thanks Paul, that does indeed explain my confusion then.

 

That's very misleading. There's no indication in the Variable Properties dialog that the setting

'Make this variable available to macros called by this macro'

does not always apply.

 

I've reported it to Insight.

 

--

Terry, East Grinstead, UK