ProjectGlobal "On" ; item to watch for

[Guilect]

I was not getting the result I was expecting from a variable in a global file in a project.

The variable was being assigned inline at declaration time, but would incorrectly (unexpectedly) return a value of 0  (or null for a string variable).

The solution was to break the declaration and assignment into 2 lines of code.

This does not work:

Code Select Expand

ProjectGlobal "ON"
def foo = 99 as int
DebugPrint "foo = " + Str$(foo)
ProjectGlobal "OFF"
returns 0

This works:

Code Select Expand

ProjectGlobal "ON"
def foo as int
foo = 99
DebugPrint "foo = " + Str$(foo)
ProjectGlobal "OFF"
returns 99

It would be nice to be able to do the inline assignment under these conditions.

Regards,
Guilect

[LarryMc]

Guilect

I suspect you are not using ProjectGlobal  as it was originally intended.

It's really designed to be used in a project with multiple source files.

It was never intended to be used in a single source file program.

The reason:
In a single source file all you have to do is declare a variable at the beginning of your program, outside of any subroutines and it is global for that program. So ProjectGlobal is never really needed in a single source file program.

In a project, which has many source files, you create a separate eba file (I always call mine globals.eba) to
put the

Code Select Expand

ProjectGlobal "ON"
int foo
string foofoo
ProjectGlobal "OFF"
I add the file to my project (right-click on file and select Insert File into Project)
Then I put this at the top of every other file in the project

Code Select Expand

$include "globals.eba"
Then in my main program I initialize all the global variables.

my visual designer has 70+ variables in the globals.eba file
that includes 10 windows and 13 dialogs.
and my project has 35 source files

LarryMc

 

[Guilect]

From first post:

in a project.

It is in an IWB project.   

I think I've got the hang of using both projects (thanks for your help from an earlier post) and
the use of the ProjectGlobal.

It is just the behavior of variables under these conditions that was a surprise.

In your Visual Designer project, do you inline assign and declare any variables?
I bet you do not.
If you had, or wish to give it a try, you would see that it fails.

Cheers.

[LarryMc]

In your Visual Designer project, do you inline assign and declare any variables?
I bet you do not.

I use 100's of these:

Code Select Expand

int i = 0
pointer pCode=NULL
uint a=0,b=0,c=0 just not in my globals.eba file

I guess I never tried the inline assignment inside my globals.eba file because I figured it would be redundant to set a variable to the same value 35 times since the globals.eba file is included in every other file.

The whole idea of global variables is that anywhere you change it, it shows up every where else with the same value.

So I guess I still contend you were trying to do something different than the way it was intended.

LarryMc

[LarryMc]

Let's try this explanation:

Before the ProjectGlobal directive was added you had to do the following to use global variables:
In one of your source files you had to have

Code Select Expand


global foo
global  foofoo
int foo=0
string foofoo=""
Then you would have to add an $include in all your other files with the following in it:

Code Select Expand

EXTERN foo as INT
EXTERN foofoo as STRING

ProjectGlobal is just a shortcut that ( in the case of my designer ) kept me from having to type

Code Select Expand

global 'variable'  70 times
'and
extern 'variable' as type  70 times
by just creating the globals.eba file, adding it to the project, and then including it in all the other project files.

LarryMc

[WayneA]

I didn't realize there was a ProjectGlobal command until just now (not in the help file?)... however I think the best way to initialize these variables (with the possible exception of strings depending on their use in the program) is the global initializer method.. ie:

Code Select Expand

uint %blarg=100The percent sign being the key difference.

[LarryMc]

The ProjectGlobal was added here - http://www.ionicwind.com/forums/index.php/topic,2057.0.html

It always has helped me to periodically go back and read those update announcements because not everything made it into the help file.

I've never used the % (although I've seen it appear from time to time) but if you want to use the % with global variables don't put the % statement in the globals.eba file or you will be executing it 1 x the numbers of eba files in your project. I'm not sure how the compiler would respond to that.

And I'm really not sure of the impact of this, from the help file:

NOTE: Using %variablename is evaluated at compile time, not run time, in as much initializers must be constant, or resolve to a constant.

I'm hoping it means that in the statement that has the % in it the variable has to be set to a constant, but that initial constant value can be changed after the program is running.

LarryMc

[WayneA]

The value can be changed but it means the initializer isn't actually executed, it just sets the default value. It also makes note in the help file that strings initialized with this method are only the length of the initial string and generally shouldn't be altered because you might accidentally overwrite memory.

Personally I would just not use this method for initializing a string at all, unless I explicitly planned to alter it at some point as $define allows creation of string constants anyways.

Thanks for the link.