LOCAL/GLOBAL variables

[FutureCow]

Can someone see if they get the same bug I do?
Create a new project, paste the following code in (it's the example from the manual page for the LOCAL command)

Code (glbasic) Select Expand

LOCAL text$
text$="LOCAL_MAIN"
GLOBAL text$="GLOBAL"

GOSUB show
PRINT text$, 100, 150
SHOWSCREEN
MOUSEWAIT
END

// ------------------------------------------------------------- //
// -=#  SHOW  #=-
// ------------------------------------------------------------- //
SUB show:
LOCAL text$

// Creating and defining LOCAL arrays:
LOCAL array[]; DIM array[5]

text$="LOCAL_SUB"

PRINT text$, 100, 50
// Is equal to
// PRINT LOCAL text$, 100, 50
PRINT GLOBAL text$, 100, 100
ENDSUB // SHOW


And execute it. The second print - i.e.

Code (glbasic) Select Expand

PRINT GLOBAL text$, 100, 100
does not show as the creation of the variable (GLOBAL text$="GLOBAL") creates an empty global variable according to the debugger.


Can you also try putting a breakpoint on the very first line of code (LOCAL text$), compile and run in debug mode and see if it works like you'd expect? I'm getting a window with "Loading..." written in it. I've got a feeling it might be related to my previously stepping through the code while up to a MOUSEWAIT command and having that earlier run not exited properly.

[StuC_Ovine]

Why are you defining text$ as a local then a global straight afterwards ?  You are contradicting yourself.

Also its not good practice to name local variables the same as globals.  (call text$  gText$ for example,  then there is no need to call GLOBAL outside of the main file)

remove your first LOCAL reference and you should see it then works.

Code (glbasic) Select Expand


//LOCAL text$
//text$="LOCAL_MAIN"


[Moru]

This is apparently the example code from the manual he is asking about, not something he wrote himself. So the question is still valid :-)

[FutureCow]

I know setting a local than a global is not good form, but as I mentioned I'm testing the example code from the documentation. Technically it should work (regardless of how poor technique it is!), hence the bug report.

Can someone else try it and confirm they see the same thing?
Also, can you try putting the breakpoint on the first line of code and see if you get the same behavior I did?

[StuC_Ovine]

Sorry I don't understand why you want to get the code working in it current form.  

Remove the local from the beginning of the code and it works as expected.  

text$ is overwritten in the function by the LOCAL and the "PRINT GLOBAL text$" shows whats in the global version of the variable.



n.b.  its wise to use the EXPLICIT DECLARATIONS in the project setup.  In which case the old code would not compile as it will grumble that text$ is not a GLOBAL (as you first declared it as a LOCAL).

[FutureCow]

I was doing some tests of my own today on scope and found it not working as I thought it should. To see what I was doing wrong I copied the example code to see if it worked, and it doesn't either. Hence there is a bug in setting scope and I'm pointing it out.
Yes there are ways around it, and in my code I tend to have unique variables for everything so I don't run into this. But that's not the point, the point is the bug might bite me somewhere down the track and here's an easy way to spot it and fix it while its 10 lines of code and not 10,000.

[Hemlos]

GLOBAL and LOCAL work fine.
If you use local and globals with the same name, declare them as such.

Try this:

Code (glbasic) Select Expand

// --------------------------------- //
// Project: test
// Start: Wednesday, September 16, 2009
// IDE Version: 7.104
GLOBAL text$="GLOBAL"
LOCAL text$="LOCAL_MAIN"

PRINT "1"+GLOBAL text$, 1, 1
PRINT "2"+LOCAL text$, 1, 30
PRINT "3"+text$, 1, 60

GOSUB show

PRINT "7"+GLOBAL text$, 400, 1
PRINT "8"+LOCAL text$, 400, 30
PRINT "9"+text$, 400, 60

SHOWSCREEN
MOUSEWAIT
END

// ------------------------------------------------------------- //
// -=#  SHOW  #=-
// ------------------------------------------------------------- //
SUB show:
LOCAL text$="LOCAL_SUB"

// Creating and defining LOCAL arrays:
LOCAL array[]; DIM array[5]

// Is equal to
// PRINT LOCAL text$, 100, 50
PRINT "4"+GLOBAL text$, 200, 1
PRINT "5"+LOCAL text$, 200, 30
PRINT "6"+text$, 200, 60

ENDSUB // SHOW

[FutureCow]

While I appreciate the responses, no one is actually testing the demo code from the documentation. Can someone please test the code from the "LOCAL" page of the documentation and confirm whether the bug exists?

[Moru]

Sorry, I didn't state so but I did test the code from the example and it doesn't compile just as you said. No need to comment on how it's supposed to be written as we have stated many times now, it's a bug. It's in the documentation but it doesn't work like advertised. Ok? Can't do it more clear like this without a stamp in the forehead I guess :-)

[FutureCow]

Thanks for doing that Moru.
Now if you could just test the breakpoint thing for me at the bottom of my post, I'll get the stamp ready for you 

[Moru]

Since it doesn't compile I can't do a breakpoint step-thru :-)

[MrTAToad]

It compiles and runs here (although I cant get breakpoints working) - and yes, I do think its a problem

[Kitty Hello]

It's a bug in the manual. The compiler complains when a LOCAL and a GLOBAL have the same name. And I think that's good.

[Moru]

I think something like this is perfectly ok though:

Code (glbasic) Select Expand


GLOBAL temp$

// Here I expect access to the global temp$

FUNCTION a_function:
    LOCAL temp$
// Here I expect temp$ to be local, no access to the global temp$

ENDFUNCTION



[FutureCow]

The line it complains about is not the one where the global is created though. If you step through just the first 3 lines of code, the global created after a local doesn't get the value assigned to it. Shouldn't it still get allocated a value?

What about the stepping through the code problem?