By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,677 Members | 1,069 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,677 IT Pros & Developers. It's quick & easy.

Global Variables nott Global?

P: n/a
I have a Module that declares several arrays as public, some string, some
integers. I then have 2 forms. Form A is the main form, that loads on
start-up, and has a command button to open Form B. On form B there are
several text boxes where the array values can be changed, however when I
close B and go back to A, those values are lost. I thought Public meant
Public?

Larry L
Jul 17 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
> I have a Module that declares several arrays as public, some string, some
integers. I then have 2 forms. Form A is the main form, that loads on
start-up, and has a command button to open Form B. On form B there are
several text boxes where the array values can be changed, however when I
close B and go back to A, those values are lost. I thought Public meant
Public?


Did you by any chance declare an array on either FormA or FormB with the
same name as the one you made Public in your Module?

Rick - MVP
Jul 17 '05 #2

P: n/a
In article <hu********************@comcast.com>, "Rick Rothstein" <ri************@NOSPAMcomcast.net> wrote:
I have a Module that declares several arrays as public, some string, some
integers. I then have 2 forms. Form A is the main form, that loads on
start-up, and has a command button to open Form B. On form B there are
several text boxes where the array values can be changed, however when I
close B and go back to A, those values are lost. I thought Public meant
Public?


Did you by any chance declare an array on either FormA or FormB with the
same name as the one you made Public in your Module?

Rick - MVP


Rick,

No, not at all. The A form reads values for the 3 arrays from a file in
Form Load and then shows itself. It's actually 6 items, with 3 pieces of
information each (1 string, 1 integer, and 1 Boolean). Those items are not
represented on form A. I then click form B to see 18 text boxes (6x3) with
those variable names, showing the values. I now see that the values in the
file are NOT shown there.

FYI, I had all this working fine on a single form, but it's cluttered, and
I wanted to move the variables input to another form (It will only be
needed at start-up).

Larry L
Jul 17 '05 #3

P: n/a
Where are you assigning the new values entered on Form B back into the
array? Global *is* global ... you've got an error somewhere.

--

Randy Birch
MVP Visual Basic
http://www.mvps.org/vbnet/
Please respond only to the newsgroups so all can benefit.
"Larry L" <la***@somewhereinhawaii.net> wrote in message
news:yH*******************@twister.socal.rr.com...
: In article <hu********************@comcast.com>, "Rick Rothstein"
<ri************@NOSPAMcomcast.net> wrote:
: >> I have a Module that declares several arrays as public, some string,
some
: >> integers. I then have 2 forms. Form A is the main form, that loads on
: >> start-up, and has a command button to open Form B. On form B there are
: >> several text boxes where the array values can be changed, however when
I
: >> close B and go back to A, those values are lost. I thought Public meant
: >> Public?
: >
: >Did you by any chance declare an array on either FormA or FormB with the
: >same name as the one you made Public in your Module?
: >
: >Rick - MVP
:
: Rick,
:
: No, not at all. The A form reads values for the 3 arrays from a file in
: Form Load and then shows itself. It's actually 6 items, with 3 pieces of
: information each (1 string, 1 integer, and 1 Boolean). Those items are not
: represented on form A. I then click form B to see 18 text boxes (6x3) with
: those variable names, showing the values. I now see that the values in the
: file are NOT shown there.
:
: FYI, I had all this working fine on a single form, but it's cluttered, and
: I wanted to move the variables input to another form (It will only be
: needed at start-up).
:
: Larry L
Jul 17 '05 #4

P: n/a
In article <xk****************@news04.bloor.is.net.cable.roge rs.com>, "Randy Birch" <rg************@mvps.org> wrote:
Where are you assigning the new values entered on Form B back into the
array? Global *is* global ... you've got an error somewhere.


Randy,

I definitely know I have an error! :-) I also know Public means it, but
can't see where the problem is. Here's what's happening -

The Program starts with Form A. In the Form A Load procedure it loads Form
B with Show. In the Form B Load procedure it calls a subroutine that reads
a file, assigning the values to the items in the 3 arrays (6 sets of 3
pieces ea). Those items do indeed show up in the text boxes of their name
on form B. However when I now go to Form A (whether or not I close B 1st)
and print the variables to a text box there (or try to use them), they are
all null. I'm lost?

Remenber this was all working fine, until I tried to move the text boxes
to a seperate form ("B"). The 3 arrays were always declared Public in the
..bas module of the project.

Larry L
Jul 17 '05 #5

P: n/a

"Larry L" <la***@somewhereinhawaii.net> wrote in message
news:BF*******************@twister.socal.rr.com...
In article <xk****************@news04.bloor.is.net.cable.roge rs.com>, "Randy Birch" <rg************@mvps.org> wrote:
Where are you assigning the new values entered on Form B back into thearray? Global *is* global ... you've got an error somewhere.


Randy,

I definitely know I have an error! :-) I also know Public means it,

but can't see where the problem is. Here's what's happening -

The Program starts with Form A. In the Form A Load procedure it loads Form B with Show. In the Form B Load procedure it calls a subroutine that reads a file, assigning the values to the items in the 3 arrays (6 sets of 3
pieces ea). Those items do indeed show up in the text boxes of their name on form B. However when I now go to Form A (whether or not I close B 1st) and print the variables to a text box there (or try to use them), they are all null. I'm lost?

Remenber this was all working fine, until I tried to move the text boxes to a seperate form ("B"). The 3 arrays were always declared Public in the .bas module of the project.

Larry L


I think you have some "residual" code from the earlier version, which is
reloading the arrays after the Form B load event completes - perhaps. in
the Form A load event, after the call to show form B.

The fact that the values show in the textboxes means only that they were
in the array when you copied the array values to the textboxes, not that
they are still there.

Step through your program from the beginning of the Form A load event,
and examine the contents of one of the array values in the debug window
after every line of code. I'm sure you'll find the spot.
Jul 17 '05 #6

P: n/a
You asked if global meant global. I said yes. My reference to 'error' meant
either some code that is not adding the updated data to the array you
expect, or failing to add it at all. Do you have Option Explicit as the
first line in every form and module? If not add that, then hit Run / Start
with full compile and see if anything breaks.

--

Randy Birch
MVP Visual Basic
http://www.mvps.org/vbnet/
Please respond only to the newsgroups so all can benefit.
"Larry L" <la***@somewhereinhawaii.net> wrote in message
news:BF*******************@twister.socal.rr.com...
: In article <xk****************@news04.bloor.is.net.cable.roge rs.com>,
"Randy Birch" <rg************@mvps.org> wrote:
: >Where are you assigning the new values entered on Form B back into the
: >array? Global *is* global ... you've got an error somewhere.
: >
:
: Randy,
:
: I definitely know I have an error! :-) I also know Public means it, but
: can't see where the problem is. Here's what's happening -
:
: The Program starts with Form A. In the Form A Load procedure it loads Form
: B with Show. In the Form B Load procedure it calls a subroutine that reads
: a file, assigning the values to the items in the 3 arrays (6 sets of 3
: pieces ea). Those items do indeed show up in the text boxes of their name
: on form B. However when I now go to Form A (whether or not I close B 1st)
: and print the variables to a text box there (or try to use them), they are
: all null. I'm lost?
:
: Remenber this was all working fine, until I tried to move the text boxes
: to a seperate form ("B"). The 3 arrays were always declared Public in the
: bas module of the project.
:
: Larry L
Jul 17 '05 #7

P: n/a
In article <ne********************@comcast.com>, "Steve Gerrard" <no*************@comcast.net> wrote:


I think you have some "residual" code from the earlier version, which is
reloading the arrays after the Form B load event completes - perhaps. in
the Form A load event, after the call to show form B.

The fact that the values show in the textboxes means only that they were
in the array when you copied the array values to the textboxes, not that
they are still there.

Step through your program from the beginning of the Form A load event,
and examine the contents of one of the array values in the debug window
after every line of code. I'm sure you'll find the spot.


I added option explicit as Randy suggested, and indeed it led me to a
logic error that had to do with mis-placed code, but that part had nothing
o do with this problem. So I added a Watch on one of the array variables,
and stepped through it. When B opens, and the data file is read, that
variable correctly gets its value, which holds right up until the code
jumps back to Form A, at which point the watch says the value is <out of
context>.

I can't find any reference to that error, but now I think I see the
problem, so tell me if this is right. In the past (when it was all on the
same form) I've defined the arrays as public, and then named the text
boxes with those names Text1(1), Text1(2) etc. Now I see that when that
form loses focus or closes, those names are not available to Form B, even
they are Public? So I actually need to name the text boxes something
different and set the variables to their values after the file read when
form B opens?

Larry L

Jul 17 '05 #8

P: n/a
You can't name controls the same name as variables.

--

Randy Birch
MVP Visual Basic
http://www.mvps.org/vbnet/
Please respond only to the newsgroups so all can benefit.
"Larry L" <la***@somewhereinhawaii.net> wrote in message
news:8v*******************@twister.socal.rr.com...
: In article <ne********************@comcast.com>, "Steve Gerrard"
<no*************@comcast.net> wrote:
: >
: >
: >I think you have some "residual" code from the earlier version, which is
: >reloading the arrays after the Form B load event completes - perhaps. in
: >the Form A load event, after the call to show form B.
: >
: >The fact that the values show in the textboxes means only that they were
: >in the array when you copied the array values to the textboxes, not that
: >they are still there.
: >
: >Step through your program from the beginning of the Form A load event,
: >and examine the contents of one of the array values in the debug window
: >after every line of code. I'm sure you'll find the spot.
: >
:
: I added option explicit as Randy suggested, and indeed it led me to a
: logic error that had to do with mis-placed code, but that part had nothing
: o do with this problem. So I added a Watch on one of the array variables,
: and stepped through it. When B opens, and the data file is read, that
: variable correctly gets its value, which holds right up until the code
: jumps back to Form A, at which point the watch says the value is <out of
: context>.
:
: I can't find any reference to that error, but now I think I see the
: problem, so tell me if this is right. In the past (when it was all on the
: same form) I've defined the arrays as public, and then named the text
: boxes with those names Text1(1), Text1(2) etc. Now I see that when that
: form loses focus or closes, those names are not available to Form B, even
: they are Public? So I actually need to name the text boxes something
: different and set the variables to their values after the file read when
: form B opens?
:
: Larry L
:
Jul 17 '05 #9

P: n/a

"Larry L" <la***@somewhereinhawaii.net> wrote in message
news:8v*******************@twister.socal.rr.com...
In article <ne********************@comcast.com>, "Steve Gerrard" <no*************@comcast.net> wrote:


I can't find any reference to that error, but now I think I see the
problem, so tell me if this is right. In the past (when it was all on the same form) I've defined the arrays as public, and then named the text
boxes with those names Text1(1), Text1(2) etc. Now I see that when that form loses focus or closes, those names are not available to Form B, even they are Public? So I actually need to name the text boxes something
different and set the variables to their values after the file read when form B opens?

Larry L


Just to expand on Randy's succinct answer, your text boxes are
essentially module level variables. I believe that in general, when
variables have the same name, the closest context rules, i.e. local
level overrides module level, and module level overrides global.
Although it is legal, it is considered bad form to have any variables or
controls with the same name, or to re-use any existing VB procedure
names. Your case is a perfect example of why.

It may also be that you are not clear that a variable and a text box are
two different things. You should be declaring an array, loading the
array from a file, and then explicitly assigning the array values to the
textboxes. There is no sense in which a textbox is "bound" to a variable
(although they can be bound to database fields, but that is a different
story).
Jul 17 '05 #10

P: n/a
In article <sN********************@comcast.com>, "Steve Gerrard" <no*************@comcast.net> wrote:

"Larry L" <la***@somewhereinhawaii.net> wrote in message
news:8v*******************@twister.socal.rr.com.. .
In article <ne********************@comcast.com>, "Steve Gerrard"

<no*************@comcast.net> wrote:
>


Just to expand on Randy's succinct answer, your text boxes are
essentially module level variables. I believe that in general, when
variables have the same name, the closest context rules, i.e. local
level overrides module level, and module level overrides global.
Although it is legal, it is considered bad form to have any variables or
controls with the same name, or to re-use any existing VB procedure
names. Your case is a perfect example of why.

It may also be that you are not clear that a variable and a text box are
two different things. You should be declaring an array, loading the
array from a file, and then explicitly assigning the array values to the
textboxes. There is no sense in which a textbox is "bound" to a variable
(although they can be bound to database fields, but that is a different
story).


Steve,

When I started this, I created a textbox, copied and pasted it, and was
asked if I wanted to create an array. I said Yes, and went from there to
create 6 boxes. I then used those names in my other code as "variables"
(sure, I know the difference). Short, sweet, simple, and it worked
perfectly. I changed the text in a textbox, and the "variable" changed,
with no other code required. They weren't seperate entities having the
same name, they were the same thing. I'm not at all sure why that's
considered bad form? It seems to me to be more efficient.

The problem came when I seperated the form into two forms. I assumed that
since I'd declared the arrays (the text boxes) in a module as public, that
they'd be available in the other form, but obviously they aren't. Now much
as you suggested, I've declared another set of variables as arrays of the
same size, and assign the values in the text boxes to those variables,
change the variables, and the assign the values back to the text boxes.
Sure was easier before I split the forms!

Thanks so much to you and Randy for your help.

Larry L
Jul 17 '05 #11

P: n/a
What precisely do you mean when you say "I assumed that since I'd declared
the arrays (the text boxes) in a module as public, that they'd be available
in the other form"?

--

Randy Birch
MVP Visual Basic
http://www.mvps.org/vbnet/
Please respond only to the newsgroups so all can benefit.
"Larry L" <la***@somewhereinhawaii.net> wrote in message
news:zu*******************@twister.socal.rr.com...
: In article <sN********************@comcast.com>, "Steve Gerrard"
<no*************@comcast.net> wrote:
: >
: >"Larry L" <la***@somewhereinhawaii.net> wrote in message
: >news:8v*******************@twister.socal.rr.com.. .
: >> In article <ne********************@comcast.com>, "Steve Gerrard"
: ><no*************@comcast.net> wrote:
: >> >
: >
: >Just to expand on Randy's succinct answer, your text boxes are
: >essentially module level variables. I believe that in general, when
: >variables have the same name, the closest context rules, i.e. local
: >level overrides module level, and module level overrides global.
: >Although it is legal, it is considered bad form to have any variables or
: >controls with the same name, or to re-use any existing VB procedure
: >names. Your case is a perfect example of why.
: >
: >It may also be that you are not clear that a variable and a text box are
: >two different things. You should be declaring an array, loading the
: >array from a file, and then explicitly assigning the array values to the
: >textboxes. There is no sense in which a textbox is "bound" to a variable
: >(although they can be bound to database fields, but that is a different
: >story).
: >
:
: Steve,
:
: When I started this, I created a textbox, copied and pasted it, and was
: asked if I wanted to create an array. I said Yes, and went from there to
: create 6 boxes. I then used those names in my other code as "variables"
: (sure, I know the difference). Short, sweet, simple, and it worked
: perfectly. I changed the text in a textbox, and the "variable" changed,
: with no other code required. They weren't seperate entities having the
: same name, they were the same thing. I'm not at all sure why that's
: considered bad form? It seems to me to be more efficient.
:
: The problem came when I seperated the form into two forms. I assumed that
: since I'd declared the arrays (the text boxes) in a module as public, that
: they'd be available in the other form, but obviously they aren't. Now much
: as you suggested, I've declared another set of variables as arrays of the
: same size, and assign the values in the text boxes to those variables,
: change the variables, and the assign the values back to the text boxes.
: Sure was easier before I split the forms!
:
: Thanks so much to you and Randy for your help.
:
: Larry L
Jul 17 '05 #12

P: n/a
(also in answer Randy's last question)

So you thought that if you started with say, Text(0) and Text(1) on a
form, you could then elsewhere declare Public Text(), and make the
textboxes be public. What you got instead was a separate array called
Text, and the subsequent confusion.

In fact, the textboxes on FormB are sort of public, in that you could
reference formB.Text(0) from code in FormA to get at one of the
textboxes. However, the textboxes on FormB are unloaded along with FormB
when it is closed, so they are never really global variables.

It may at first seem a pain to load values into variables, then "write"
the variables into textboxes, parse a user's edit, and "write" the new
value back to the variable. In the long run though, it allows much more
control over what happens with bad input, undo buttons, formatting
currency, etc. It also lets you change your mind about how to display
something (checkbox? list? grid?), without affecting how you use the
value in code. Once your programs start getting a little bigger, it is
the only way to fly.

Have fun.
Steve

"Larry L" <la***@somewhereinhawaii.net> wrote in message
news:zu*******************@twister.socal.rr.com...
In article <sN********************@comcast.com>, "Steve Gerrard" <no*************@comcast.net> wrote:

"Larry L" <la***@somewhereinhawaii.net> wrote in message
news:8v*******************@twister.socal.rr.com.. .
In article <ne********************@comcast.com>, "Steve Gerrard"

<no*************@comcast.net> wrote:
>


Just to expand on Randy's succinct answer, your text boxes are
essentially module level variables. I believe that in general, when
variables have the same name, the closest context rules, i.e. local
level overrides module level, and module level overrides global.
Although it is legal, it is considered bad form to have any variables orcontrols with the same name, or to re-use any existing VB procedure
names. Your case is a perfect example of why.

It may also be that you are not clear that a variable and a text box aretwo different things. You should be declaring an array, loading the
array from a file, and then explicitly assigning the array values to thetextboxes. There is no sense in which a textbox is "bound" to a variable(although they can be bound to database fields, but that is a differentstory).


Steve,

When I started this, I created a textbox, copied and pasted it, and

was asked if I wanted to create an array. I said Yes, and went from there to create 6 boxes. I then used those names in my other code as "variables" (sure, I know the difference). Short, sweet, simple, and it worked
perfectly. I changed the text in a textbox, and the "variable" changed, with no other code required. They weren't seperate entities having the
same name, they were the same thing. I'm not at all sure why that's
considered bad form? It seems to me to be more efficient.

The problem came when I seperated the form into two forms. I assumed that since I'd declared the arrays (the text boxes) in a module as public, that they'd be available in the other form, but obviously they aren't. Now much as you suggested, I've declared another set of variables as arrays of the same size, and assign the values in the text boxes to those variables,
change the variables, and the assign the values back to the text boxes. Sure was easier before I split the forms!

Thanks so much to you and Randy for your help.

Larry L

Jul 17 '05 #13

P: n/a
In article <3s********************@comcast.com>, "Steve Gerrard" <no*************@comcast.net> wrote:
(also in answer Randy's last question)

So you thought that if you started with say, Text(0) and Text(1) on a
form, you could then elsewhere declare Public Text(), and make the
textboxes be public. What you got instead was a separate array called
Text, and the subsequent confusion.
Essentially exactly what I thought, as I had declared the names in a
module, which as I understand it, runs before the forms are loaded, thus
my assumption that they were Public.
In fact, the textboxes on FormB are sort of public, in that you could
reference formB.Text(0) from code in FormA to get at one of the
textboxes. However, the textboxes on FormB are unloaded along with FormB
when it is closed, so they are never really global variables.
Actually I don't close A, I just make visible=false, so I apparantly could
indeed call on those values.
It may at first seem a pain to load values into variables, then "write"
the variables into textboxes, parse a user's edit, and "write" the new
value back to the variable. In the long run though, it allows much more
control over what happens with bad input, undo buttons, formatting
currency, etc. It also lets you change your mind about how to display
something (checkbox? list? grid?), without affecting how you use the
value in code. Once your programs start getting a little bigger, it is
the only way to fly.

Have fun.
Steve
Steve, it has indeed been some form of "fun" for all values of Fun=
Frustration with added learning! I actually learned to program on a
machine with 48k of memory and 100k floppys that had to hold all your code
and your data. We scrutinized every routine for maximum efficiency, which
I still do by nature. Todays paradigm is far different, and I haven't
written any code in 10 years. Vbasic was a real challenge to get my head
around, and I've tried to learn it from a couple of books, that suggested
the very methods that were failing for me.

I genuinely appreciate all your time, and for me at least it's actually
paying off. The project still has a way to go, but is working. Most of the
problems I now have are due to some complicated logic issues, and the fact
it must run on both 98 and XP, and it's using api calls that don't work
the same way on both, (like SetForegroundWindow).

I'm still ahving fun!
Larry L [in Honolulu]
"Larry L" <la***@somewhereinhawaii.net> wrote in message
news:zu*******************@twister.socal.rr.com.. .
In article <sN********************@comcast.com>, "Steve Gerrard"

<no*************@comcast.net> wrote:
>
>"Larry L" <la***@somewhereinhawaii.net> wrote in message
>news:8v*******************@twister.socal.rr.com.. .
>> In article <ne********************@comcast.com>, "Steve Gerrard"
><no*************@comcast.net> wrote:
>> >
>
>Just to expand on Randy's succinct answer, your text boxes are
>essentially module level variables. I believe that in general, when
>variables have the same name, the closest context rules, i.e. local
>level overrides module level, and module level overrides global.
>Although it is legal, it is considered bad form to have any variablesor >controls with the same name, or to re-use any existing VB procedure
>names. Your case is a perfect example of why.
>
>It may also be that you are not clear that a variable and a text boxare >two different things. You should be declaring an array, loading the
>array from a file, and then explicitly assigning the array values tothe >textboxes. There is no sense in which a textbox is "bound" to avariable >(although they can be bound to database fields, but that is adifferent >story).
>


Steve,

When I started this, I created a textbox, copied and pasted it, and

was
asked if I wanted to create an array. I said Yes, and went from there

to
create 6 boxes. I then used those names in my other code as

"variables"
(sure, I know the difference). Short, sweet, simple, and it worked
perfectly. I changed the text in a textbox, and the "variable"

changed,
with no other code required. They weren't seperate entities having the
same name, they were the same thing. I'm not at all sure why that's
considered bad form? It seems to me to be more efficient.

The problem came when I seperated the form into two forms. I assumed

that
since I'd declared the arrays (the text boxes) in a module as public,

that
they'd be available in the other form, but obviously they aren't. Now

much
as you suggested, I've declared another set of variables as arrays of

the
same size, and assign the values in the text boxes to those variables,
change the variables, and the assign the values back to the text

boxes.
Sure was easier before I split the forms!

Thanks so much to you and Randy for your help.

Larry L


Jul 17 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.