macros and frames

[Niels Henrik Bruun]

Dear all,
I've grown quite fond of using frames in my code.
However, sometimes when running a do-file with a few active frames in my code, my macros get strange values and I get strange error messages like matrix errors after a generate command.
I can not reproduce or isolate the problem.
Maybe it is just me using frames the wrong way.
But if more have similar problems, we can address the Stata helpdesk.

[William Lisowski]

For the benefit of others who may find this at a later date, you are not expecting that a local macro is restricted not only to the program within which it is defined but also to the frame within which it was defined?

. local message I'm here

. display "`message'"
I'm here

. frame create foo

. frame foo {
.     local message Hello, world!
. }

. display "`message'"
Hello, world!

.

But with that said, the following demonstrates that some components of creturn() differ between different frames. And there's a difference between the results from frame {} and those from frame : - and this example is based on a personal misadventure.

 frame create foo

. frame foo {
.     set obs 2
Number of observations (_N) was 0, now 2.
. }

. display c(N)
1

. display `c(N)'
1

. frame foo: display c(N)
2

. frame foo: display `c(N)'
1

. frame foo {
.     display c(N)
2
.     display `c(N)'
2
. }

.

So I find your description of problems plausible, and perhaps these examples can help you find a reproducible example.

[William Lisowski]

Let me add: the second example in post #2 was not fully copied, I omitted the initial set obs 1 in the default frame.

So the first two display commands are run in, and report the results for, the default frame; the third display command runs in, and reports the results for, the foo frame; the fourth display command Stata evaluates `c(N)' in the default frame and the displays that result from the foo frame; and the final two display commands are run in, and report the results for, the foo frame.

[Bjarte Aagnes]

Seems this difference in behavior is not described in the documentation of frame prefix.

[William Lisowski]

I think it's sort of implicit that Stata substitutes for `...' constructs as early as possible. I'm not sure where in the documentation I'd find that explicitly, but I think it's the most easily remembered rule they could have come up with.

Actually, when I look at [U] 18.3.12, I see no support for for my use of c(N) without the `' surrounding it. I was going to blame this on the display command being too helpful, but replacing all the display commands in my example with scalar definitions (e.g., scalar n1 = c(N))yields the same sequence of results - 1 1 2 1 2 2.

And interestingly, if you're into "characteristics" (help char), the macro function char

local foo : char varname[bar]

is apparently also accomplished by

local foo `varname[bar]'

[Mia Lv (StataCorp)]

The macros in Stata commands will be expanded before Stata executes the command. So when you have

      frame foo :  display `c(N)'

Stata will treat it like

     frame foo :  display 0

and execute it, because in the current frame, the macro `c(N)' equals 0.

I hope it helps.

[Niels Henrik Bruun]

Thank you all for commenting. After the comments, I've been thinking. And I can be a bit specific.
One feature regarding frames is that they exist in the command window after being created in a do-file.
This is convenient both for validation of code and error finding.
Further, I can do my analyses on different populations in the order I prefer.

I've had up to a max of 10 frames open at a time on datasets with a max of 500 rows.
What I experience is, that after changing to a certain frame, I reset a local, e.g., named lgd for the content of the legend option in the twoway command.
Then I build the content of local lgd using for-loops.
When the code section is run, everything seems fine.
But when the whole do-file is run, the local lgd is not set correctly. Text blocks are sometimes added and text might be substituted with something else.
I've found a workaround by adding -macro drop _all- after I change to a frame. But that should not be necessary, since I had reset lgd by local lgd.

Later, when I started getting matrix errors after a generate command, I got really worried.

[Mia Lv (StataCorp)]

Can you send your question (with an example do-file) to [email protected]? We will be glad to take a closer look.

[Niels Henrik Bruun]

Gladly, if I could. But I can't reproduce it without compromising customer data.
Further, it appears periodically.
The Stata helpdesk gives wonderful support, which I benefitted from several times.
But if it can't be reproduced, then what can they/you do?
This is why, I chose to write about my problem in this post.
Maybe it is just me doing things the wrong way.

[Bjarte Aagnes]

can't reproduce it without compromising customer data.

Some form of synthetic data would probably be OK to share and still show the problem.

Further, it appears periodically.

ref #7 Are you mixing use of command window and code? Then, maybe some experimenting with local definitions via command window and frames may trigger what you have observed.

[Niels Henrik Bruun]

Dear all,
Thank you very much for your help.
I think the proper way to proceed is that I isolate the code giving the problem.
Then I'll contact the Stata helpdesk for help.
I promise to bring our findings here.
However, it may take some time before the problem is isolated.