Global Variable Persistance & Scope

[SNusa]

What is the scope, and reason for the following:

I am able to create a "global variable" while editing an event (which is directly attached to an object on a form) by clicking "V" on the Alpha toolbar at top of screen.

This "global variable" does not appear anywhere elsewhere after I finish editing the event itself.

It appears to be available to only that items event(s).

This "global variable" is also displayed in the drag drop lists, prefixed with a "pg."

I can't seem to use the variable in any way, because even though it is set to be pre initialized when the "database opens" I can't display it's value.

I can drag it onto the form from "drag and drop" but no values ever appear.

I also noticed that I can create a real "global variable" with the exact same name which works fine.

Is this a bug?
Are there other places similar "limited scope global variables" exist with different prefixes?

[Peter.Greulich]

Re: Global Variable Persistance & Scope

I am able to create a "global variable" while editing an event (which is directly attached to an object on a form) by clicking "V" on the Alpha toolbar at top of screen.

This "global variable" does not appear anywhere elsewhere after I finish editing the event itself.

It does for me.

It appears to be available to only that items event(s).

Nope, it's global all right.

This "global variable" is also displayed in the drag drop lists, prefixed with a "pg."

I don't see any "pg" - except for my initials.

I can't seem to use the variable in any way, because even though it is set to be pre initialized when the "database opens" I can't display it's value.

To be honest w. you, I have never used that "pre initialized " dialog to create globals for my apps. I would humbly suggest that you create an autoexec script for that purpose.

e.g. create a script, name it autoexec

Dim Global vDB_name as C = "Alpha Five"

I can drag it onto the form from "drag and drop" but no values ever appear.

Again, they do for me.

I also noticed that I can create a real "global variable" with the exact same name which works fine.

Not sure how you are creating a real one, but sure, they work.

Is this a bug?

I doubt it.

Are there other places similar "limited scope global variables" exist with different prefixes?

Not that I know of.

[SNusa]

Re: Global Variable Persistance & Scope

Very strange. I have the latest build of version 9.
(clean install - a few days ago on vista pro - I know...)

Humor me....
Create a dummy button on a form.
Right click & create an event such as "onPush."
Save the event. (any event should do, but don't create the global variable just yet....)
Save everything....
Now...
Go back to the button, right click and edit the event.
The Alpha toolbar changes (shrinks to a smaller one), but the V icon still remains as an available "tool."
Now create the global variable as follows:

While editing the x-basic or action-script, click on the V.
Create a global variable in the tab at the right. (making sure the "initialize at startup" tab is selected.
Save it.

Go back to just the form in edit mode.
Take a look at the "Drag & Drop" list.

There is the variable with the pg. prefix.
If you created a variable such as cGvar1 it appears as pg.cGvar1 and although it can be used, it appears to be useless everywhere!

I'm going to send in a bug thing.

Over the past 3 versions, I kept starting to work with them, but I continuously found issues and bugs. I found quite a few things that were verified, and they were "going to fix" in upcoming patches. As a result of all the frustration, I keep walking away from committing to this tool.

Finding these bugs (at first thinking it was my ignorance) created much frustration during the learning process.
So each time I abandoned my efforts, hoping the next version was cleaner.

If you follow the exact method above, I'd be amazed if you don't see the same thing happening.

Either something has got to be wrong, or something here is undocumented. I can't find a reference to it anywhere.

[Scott_Walker]

Re: Global Variable Persistance & Scope

Robert,

I followed your steps. After defining the global variable, in the drag & drop list I see two variables:

cGvar1 and pg.cGvar1

Regards,

Scott

[SNusa]

Re: Global Variable Persistance & Scope

Anyone else know why this is happening?

I usually get a fast respons to submitted Alpha bugs. (And through the years, I've found a bunch of them.) But I got nothing back from them on this one yet.

I'm thinking it's either a partially implemented feature, or the global variable is not being properly referenced "on save."

[G Gabriel]

Re: Global Variable Persistance & Scope

There is the variable with the pg. prefix.
If you created a variable such as cGvar1 it appears as pg.cGvar1 and as lthough it can be used, it appears to be useless everywhere!

No bugs.
Alpha is trying to do you a little favor, and as always, no favor should go un-punished:

The global variable you created is there and you could use it anywhere you want. So what's with the pg?
It's a name space, it is the "Big Mama" house for your global variable and any other global variables you might want it to live in this house.

To understand this concept, go to your IW and type:
?pg
You will get the idea.

[Tbaker]

Re: Global Variable Persistance & Scope

FWIW

Any global variable that you create while in the interactive mode or the code editor by clicking on the "V" and when the global variable genie comes up you click on the tab "Initialize at startup" and add the global variable there will then come up in the drag and drop list for forms, reports etc with the prefix PG. and will also show at the bottom of the variable list without the pg prefix.

edit: Also those global variables are the variables that will show if you use what Gabe has suggested in interactive window ?PG

Again FWIW.

Tom Baker

[SNusa]

Re: Global Variable Persistance & Scope

Please excuse my ignorance, but what is the point of this second reference of a global variable which initializes to ""?

The weird thing I noticed is that this second variable (somehow related to the original one) can be set via coding... ie:

pg.vgVar1=777

Now there are two variables with different values.
vgVar1 still equals whatever it was set to...
And the other one (pg.vgVar1 has a different value of 777.)

[Finian Lennon]

Re: Global Variable Persistance & Scope

I don't usually declare variables as you have but, the pg pointer refers to what is called (I think) the global variable namespace. You can refer to three such pointers in xbasic, global_variables(), session_variables() and local_variables().

You can demonstrate this as follows .. suppose you have declared, in a script somewhere

dim global varChar as C = "X"

then in the interactive window

dim gv as p = global_variables()
?gv.varChar
"X"
?varChar
"X"

varChar = ""
?gv.varchar
""

There aren't two values. The variable, whether referred to via the pointer or by the simple variable name, contains the most recently assigned value.

[MikeC]

Re: Global Variable Persistance & Scope

Robert,
I have seen the pg. prefix once , but figured it to be some Alpha remnant that surfaced from one of the patches--as it did not interfere with anything I figured to wait to ask about it as most likely it would be taken care of in due course....

You asked the purpose of it....probably an internal use and seeing as how I did not create the variable And it is not a system variable, it did not even occur to me to try to use it.

Is it a bug?? As it apparently doesn't cause problems, I don't think so....more likely, as I said prior, a remnant (as a generic description).


Just my thoughts...

[G Gabriel]

Re: Global Variable Persistance & Scope

Please excuse my ignorance, but what is the point of this second reference of a global variable which initializes to ""?

What is the pg and what is it for?
PG:
P: for Pointer. The name space is a pointer variable.
G: for Global.
The decoding of the name is a guess on my part and is inconsequential.
Hence, PG.. just a name for the mother variable, but any other name will do.

What is a "name space"?
It is the mother variable, the "Mother Ship". It's a dot variable. I will translate to English in a minute.
When you created the variable the way you did, alpha by default creates a name space, then the specific variable you dim'd.
Why?
Because it makes it more convenient to you.
How?
The big variable could have multitudes of other variables all within that name space. So for instance, you could have a name space (which is nothing but a variable) and call it whatever it is you want to call it, alpha just called it PG, and then this name space (variable) will have dot variables, in this case the variable you dim'd is one of them. You could have:
PG.First as C
PG.Last as C
PG.Street as C
PG.City as C
PG.Age as N
and so on..all within the same name space (PG). This enables you to use these variables together to update say another dot variable in one swoop.

Alright, forget about all these hieroglyphics. Here is the English version:
Think of a variable as a field in a table. In fact, it is just that. Yes, but that table is not a physical one, it is not stored on your harddrive, it floats in memory. It is created by alpha whenever you dim a variable. If a variable is the equivalent of a field in a table, a name space is the equivalent of the table itself. So, now you have a virtual table in memory, available globally, named PG, that has as one of it's field that variable you dim'd and you could add more and more fields (variables) to it any of which will also be available globally since the table itself is global. Just as you can append, update etc to or from a table, you can do the same with this virtual table, of course the syntax is different but the concept is the same.
Is this documented anywhere in the help file? Perhaps. Most certainly not in the Snoop Dog vocabulary I used and found more helpfull in decoding and explaining this kind of things. If this is not clear enough, I will try the "Ludocris", P Deddy or the LL Cool J version.

[SNusa]

Re: Global Variable Persistance & Scope

Everything as explained makes sense to me.
I was thingking "page global."

But in testing, there is one inconsistency with regards to your (Finian Lennon) indication that both references to the variables are the same.

I create a test form, and created a button with an event with which I created a global variable, and set it to a value.

Now, with the page running, I invoke the debugger and set two watch variables. One variable with, and one without the "pg" prefix.

The one without the prefix shows the set value. The one with does not. Going back into edit mode, I can assign separate values to both references of this "same variable."

Upon checking the values, each "instance" of the variable (with and without the namespace "pg." prefix display different values.

The one interesting thing I did find out is that by setting the value of a global variable (while editing an objects event) does in fact make it available as soon as Alpha5 loads the database, regarding whether or not the form it was created on has been "loaded / run."

This is contrary to other global variables (created at the form level, not while editing an event.) As global values created in this manner are not "initialized" until the actual form where they were created is "loaded / run."

[G Gabriel]

Re: Global Variable Persistance & Scope

Let's sort things out:
The pg part: is not a bug
It is intended by a alpha and for a purpose.

It does seem however that the assignment of values to these variables using this method does not work as intended. That part is a bug.

You might report that part as a bug, but with all the means available to create variables, this is most definitely the one least used by anyone. Just dim your variables as you write your script.

[martinwcole]

Re: Global Variable Persistance & Scope

Gabriel - question:
background for the question:
a few years ago at a conference someone was giving a speech and was particularly critical of using global variables. Since I use global variables a lot (a big app of mine may have 100 or more global vaiables,) I was troubled by his comments. But since I have never run out of memory or had any issues, I continued/continue to use global variables.

the question: if you even agree with this fellows ranting, would you say using dot globals is any more efficient for memory than just listing them individually?

[csda1]

Re: Global Variable Persistance & Scope

Hi Martin,

a few years ago at a conference someone was giving a speech and was particularly critical of using global variables. Since I use global variables a lot (a big app of mine may have 100 or more global vaiables,) I was troubled by his comments. But since I have never run out of memory or had any issues, I continued/continue to use global variables.

the question: if you even agree with this fellows ranting, would you say using dot globals is any more efficient for memory than just listing them individually?

I don't know if it was myself or Cal, or someone else, who said it, but many would agree that the less number of global variables, the better.

But Global variables, or for that matter, and scope of variable does not matter whether it is accessed via a pointer or not. It pretty much amounts to the same thing. A global variable named xyz can also be accessed as such;

dim global xyz as c
xyz="123"
?xyz
= "123"
?global_variables().xyz
= "123"
gv=global_variables()
?gv.xyz
= "123"
altptr=global_variables()
?altptr.xyz
= "123"

It uses the identical memory for storage no matter how it's location is resolved. The only thing that is different is that items dimension global, shared or local go into specific pointer spaces, as opposed to explicitly referencing a pointer. If an item is referenced and not dimensioned, it searches for the name in 1st local, then shared, then global variables to resolve the name. This can cause collisions of names that are used in operations like query.filter. That's why dimensioning is so important.

The reasons for not using global variables include some of the following;

1. Alpha's built-in functions, use or generate a lot of global names, some very common, like

body
pointer_name
xx
xxx
query_name

These will cause problems with your code if you use the same names and happen to call functions using them. I had 1 client who ran into this by a global name of his own. If instead, you create a very unique global pointer like

dim global MartinsGobalValues as P

and then create and reference all of them via the pointer (or by using with/end with), you will never have an issue with name collisions.

2. When more than 1 session accesses the same variables and were not intended to, e.g. a variable named temp, you'll run into the same problem, and in fact, each session can be messing with the other session's variables. That is the reason for Shared or Local variables

Read my tips page on this that covers a lot more on this subject