Global Madness

Dan Shafer revdan at danshafer.com
Tue Mar 22 00:16:16 EST 2005


Howard....

I spent a good bit of time testing this today, and I'm about as 
bewildered as you on some levels. That may or may not be comforting. 
LOL

There definitely seems to be something wrong with globals in 2.5.1. I 
think you are onto something. NOt sure exactly what, though.

I was able to reproduce your problems with the message box "put" 
statements precisely. I added another line to your script that reads:

answer "gHeightScaler" is among the items of the globalNames

This dialog consistently returns "false" even though the global has 
clearly been defined. At first, I thought perhaps the problem was that 
a global ceases to exist when the script in which it is defined is no 
longer executing (which is, actually, what I expected to find; I think 
that's how HyperCard worked). But I was wrong. When I put an explicit 
value into gHeightScaler in the script, then the message box recognizes 
it as a global and reports its value correctly. And, as you reported, 
thereafter as long as you keep running that script even after 
commenting out the explicit value assignment and recompiling, the 
global is recognized. It is *almost* as if Rev were insisting the 
variable be declared by assigning it a value before it would recognize 
it.

So I tried another test. I put this group of lines at the end of your 
handler:

put previewHeight/sHeight into gHeightScaler
answer "gHeightScaler" is among the items of the globalNames titled 
"After calculating value"
put 0.007312 into gHeightScaler
answer "gHeightScaler" is among the items of the globalNames titled 
"After specific value assigned"
put gHeightScaler
answer "gHeightScaler" is among the items of the globalNames titled 
"After putting to msg"

I commented and uncommented these lines in pairs, removed the stack 
from memory and restored it, quit Rev and restarted, and I concluded 
that:

1. Rev does not recognize the global in any circumstance unless it has 
had an explicit value put into it at least once.
2. Thereafter, it behaves correctly until you quit Rev and re-launch 
with the explicit value assignment lines commented out, in which case 
it reverts to its incorrect behavior of not recognizing the global for 
the purposes of the message and for including the global in the 
globalNames.
3. However -- and this is where it gets really mysterious to me -- it 
NEVER fails to pass the correct value of the global to other handlers 
in the same script, no matter whether I've "initialized" it. So I was 
NOT able to reproduce that particular aspect of the behavior you 
mentioned.

This means, I think, that while globals appear not to work or register 
correctly in the IDE, they work fine in the actual stacks (and 
presumably the apps created from those stacks). Obviously, if you check 
the globalNames in a script to determine whether a given global has yet 
been defined, you will get an erroneous result if this is indeed a bug.

Just for grins, I went back to 2.5 and 2.2.1 and tested this with 
identical results. So this is the way globals have behaved for a long 
time, which means it may be intentional and simply obscure.

Dan


On Mar 21, 2005, at 7:58 PM, Howard Bornstein wrote:

> On Tue, 22 Mar 2005 14:15:56 +1200, Glen Boyd <glenb at napier.govt.nz> 
> wrote:
> ?
>>
>> Have you declared this global in all stacks that require access to it?
>> If I recall correctly you need to specify the global in each stack 
>> that
>> you wish to use the variable globally in.
>
>
> Yes. If you saw my test script I declared it at the beginning of the
> handler and only called it from that handler. I'd really appreciate it
> if someone could test this on another machine. It's a simple script,
> it's right there for you to copy and paste, and it just goes into a
> button.
>
> Thanks.
> -- 
> Regards,
>
> Howard Bornstein
> -----------------------
> www.designeq.com
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>



More information about the Use-livecode mailing list