Loosing Global Variables

[Stan Mathews]

Re: Loosing Global Variables

but the statement, if followed, would eventually lead to everyone leaving the room, ostensibly forever in search of a room in which they were not the smartest.

Possibly. I've never been in such a situation.

[MoGrace]

Re: Loosing Global Variables

So, Stan - you're never alone? ;)

Being the smartest person in the room has its own difficulties...

[martinwcole]

Re: Loosing Global Variables

There were cases in 4.5 where, when you were using stuff like query.filter=, unless you dimmed a variable (even though it was a global variable) the query would fail - not sure if that is still the case

but if you "dim global vdate as d=date()" in the autoexec
in a script you can say
dim global vdate as d
and it will not change the value of vdate
then, when writing the script, the variable is in the autofill/find when writing the script

[DaveM]

Re: Loosing Global Variables

Bringing up an old thread that came to mind last night and maybe help someone in the future.

Trying to dim a variable as global when it already was did NOT work. Once I realized it was already there, I played with it a bit. If I created it again and supplied a new vaue, it would work within the script with the assigned value. Once out of the script, the original value cam to life.

variable name is vxaddress and is dimmed in a main for to be used constantly from the application. I globally dimmed the same name, tried to open a form and fill a fill a field with the contents to find the contents wrong.

When I figured it all out. I simply gave the existing global variable a new value and all was well.

My point: Do not dim a global variable a second time since the results can come out way wrong. Just give it a new value! Pretty much what Martin above and several of us have said in this thread

[martinwcole]

Re: Loosing Global Variables

dave,
if you say dim global xxx as c="xxx"
and it was already declared previously as global, it won't work
but if you say dim global xxx as c; xxx="xxx", it will work, and persist. It has always been this way, as far as I know.

[DaveM]

Re: Loosing Global Variables

it was dimmed as dim global vxaddress = "" which is how I dim my variables. Then a value of "123 main st" was inserted by var->vxaddress = "123 Main St"
in another part of the form where I would open a form with one field on it the variable would be read into it oninit. I mistakenly dim the variable as global again with a different address. I still got "123 main st", no matter what the new one was.
The view global variables showed the old address as well. It never changed.
Once I did not dim again and just did var->vxaddress = "3985 Wilson st" it worked fine.

Possibly, how you dim is part of it?
dim global sss as c = "abd"
may be different than
dim global sss as c
var->sss = "abd"

Do not know.

I (for 1) always keep variables as the same type. If it starts as c, it stays a c

Note: This is being done in v12, but it is the same in v11.

[MoGrace]

Re: Loosing Global Variables

dave,
if you say dim global xxx as c="xxx"
and it was already declared previously as global, it won't work
but if you say dim global xxx as c; xxx="xxx", it will work, and persist. It has always been this way, as far as I know.

Always been that way? and where did you discover that? Usually if I dim a global var in a script it's because the calling script has set the value already. Now I'll have to check if I do the dim and = thing as part of the dim statement.

Man, just what I needed - something else to worry about....

Btw, its not loosing, its losing

[martinwcole]

Re: Loosing Global Variables

way back when - maybe ver 5, don't remember
the documentation said that they had added a new feature
that you could say dim global varname as c="somevalue" (giving it an initial value)
BUT
once you say that, you cannot use the same syntax a second time somewhere else

for example:
in the autoexec script you say
dim global varname as c="xxx" (you have dimmed it and given it an initial value)

now, in a later script you say
dim global varname as c="yyy"
it will not override and persist

BUT
if you say dim global varname as c
varname="yyy"
it will override and persist

NOTE: you DO NOT NEED to dim it again once it is initially dimmed - it's value will not change, and it will not go away.
to change it's value, you DO NOT need to dim it again (unless you are using option strict, requiring all variables to be dimmed in all scripts) - just say varname="yyy"
because iti was initially dimmed as global it will remain in memory until you close the app.

[Stan Mathews]

Re: Loosing Global Variables

Agreed 100% Martin, with the slight variation that I always try to include dim statements in other scripts to establish the variable being referenced. Generally I dim and set the initial variable value in a form's Define New Variables dialog. Then the scripts of any buttons on the form include a simple dim <scope> varname as C (or other type).

As you say, probably not necessary but when editing such a button script at a later time I can at least see the scope of the variables referenced and that they were initialized somewhere earlier.

[MoGrace]

Re: Loosing Global Variables

Ok, I think I've got it.

dim scope var as c = "xxx"

can be used to initially create the var but once created, shouldn't be used that way again.

Instead the 'old' way is how to dim an existing var and populate it:

dim scope var as c
var = 'xxx'

This is where having a book to review these basics is better than the online wiki search, IMO. I have reviewed variable scoping, and never ran across this one before.

[martinwcole]

Re: Loosing Global Variables

Stan,
I frequently redim the global variables, too, as it makes them available in the auto populate thingy when writing the script

Mo,
Lots of stuff is in the release notes, but/and never gets to the documentation
I think the original reason for the "initial" declaration process was for use in functions

if you say dim global xxx as c
and then xxx="xxx"

you will never go wrong and never have a problem with global variables

[MoGrace]

Re: Loosing Global Variables

Hi Martin,
Problem is I am easily impressed with the scripting of others here and have used the 'new' method quite often without apparently understanding what I was doing! And some of my scripts have had some trouble gathering the info I expected to retrieve - at least now I have a clue as to why that might be.

probably a good time to pull out the Aims App Analyzer and review my udf's...

[DaveM]

Re: Loosing Global Variables

exerpts from an autoexec

dim global compadd as c
dim global compadd2 as c

var->compadd = tbl.addr1
var->compadd2 = tbl.addr2

as opposed to

dim global compadd as c = tbl.addr1
dim global compadd2 as c = tbl.addr2

When you do this in a form, you have to give a value of some kind because the type is determined by that value. Earlier versions were not quite the same.
It could be suggested that form declared variables be set in xbasic using the oninit of that form as I am going to do in the future.

[Stan Mathews]

Re: Loosing Global Variables

When you do this in a form, you have to give a value of some kind because the type is determined by that value.

When you do it in the oninit or any other script the dim statement assigns a value. Just personal preference.

dim global compadd as c
? compadd
= ""

dim global nompadd as N
?nompadd
= 0

dim global lompadd as L
? lompadd
= .F.

dim global dompadd as D
? dompadd
= { / / }

[G Gabriel]

Re: Loosing Global Variables

Trying to dim a variable as global when it already was did NOT work.

What do you mean, "did not work"? What messge do you get?

If I created it again

I thought it "didn't work" !