Where should declarations be? Data Entry & Form Control

L

liz

I have a userform with various related procedures. My question is
this:

1. if I make all my declarations in the first executed procedure do
they hold good fro all the procedures or do i need to declare them in
each? I have an initialize, an OK and a Cancel procedure.

2. This might happen:
a. show form
b. user enters values
c. values are invalid in some way
d. return control to the form for user to re-enter
e. continues till all values valid

How do I return control to the form?

thank you

luca
 
K

Karl E. Peterson

I have a userform with various related procedures. My question is
this:

1. if I make all my declarations in the first executed procedure do
they hold good fro all the procedures or do i need to declare them in
each? I have an initialize, an OK and a Cancel procedure.
Click to expand...

In general, the goal is to reduce exposure as much as possible. So, variables that
aren't needed throughout the module should be declared at teh procedure level.
Those needed in multiple procedures would be declared at the module-level (up top).
2. This might happen:
a. show form
b. user enters values
c. values are invalid in some way
d. return control to the form for user to re-enter
e. continues till all values valid

How do I return control to the form?
Click to expand...

Hide it when Cancel is pressed. Hide it when Okay is pressed *if* valid data has
been offered. If the data are invalid, spit at the user and refuse to budge. <g>
 
L

liz

In general, the goal is to reduce exposure as much as possible. So, variables that
aren't needed throughout the module should be declared at teh procedure level.
Those needed in multiple procedures would be declared at the module-level (up top).
Click to expand...

So does this mean this: in a module (and I assume in the code related
to a form) if I put all decalariations at the top of the module are
they always evaluated first prior to any code being exceuted? And can
you explain what you mean by "exposure" please.
Hide it when Cancel is pressed. Hide it when Okay is pressed *if* valid data has
been offered. If the data are invalid, spit at the user and refuse to budge. <g>
Click to expand...

Unless I'm being stupid I don't understand. I am hiding & unloading
and as I understand it I should also set the form to nothing to ensure
that it is removed from memory, this is when eithe everything os OK or
Cancel or Close is invoked. But if the data entered is invalid I need
to understand how to "spit at the user", how does it work? If the form
is already displayed does it stay loaded and can I make it "modal" as
in Access so that comntrol stays with it untill it is either completed
or cancelled? So if the code has done the "check if valid" and found
the data to be invalid if I exit the procedure is control back with
the user? Sorry to be so dumb, but this is 3 days of learning very
fast!!!
 
J

Jay Freedman

Liz,

Let's start with how the userform is called. Say you've created a
userform definition and named it InputUF. (You should always rename
forms from the default UserForm1 to something informative.) Then in a
module, you'll write a macro -- maybe AutoNew or AutoOpen, or
something else, which I'll call demoMain -- to start the userform. VBA
will let you do that by writing the single line

InputUF.Show

but that's really not a good way to do it. Instead, consider the
userform definition to be a "template" or "cookie cutter" for making
new userforms. This code uses the New statement to make a copy of the
InputUF definition, runs the copy with the Show statement, and
destroys the copy by setting it to Nothing.

Sub demoMain()
Dim UFcopy As InputUF
Set UFcopy = New InputUF
UFcopy.Show
Set UFcopy = Nothing
End Sub

In the userform's code, when you call Me.Hide to remove the userform
from the screen, execution resumes in the demoMain macro at the line
after the .Show statement. Until you call Me.Hide, though, the
userform stays on the screen and has the input focus.

Now, here's how this works for validating input. Let's say the
userform is very simple, just a text box named textInput, an OK button
named cmdOK, and a Cancel button named cmdCancel. In the code of the
userform, besides whatever other procedures you have -- such as
Userform_Initialize -- you'll have click procedures for the two
buttons. This example shows only how to make sure there is something
in the text box.

Private Sub cmdCancel_Click()
Me.Hide
End Sub

Private Sub cmdOK_Click()
If Len(Trim(textInput.Text)) > 0 Then
' there is something other than blanks
Me.Hide
Else
' the box is empty or blanks
MsgBox "Please enter text"
textInput.SetFocus
End If
End Sub

The If statement tests whether the text in the box, not counting any
blank characters, is at least one character long. If it is, then the
Me.Hide runs and execution goes back to the demoMain macro. If the box
is empty or contains only blanks, the user is shown a message (what
Karl meant by "spit at the user") and the cursor is moved from the OK
button back to the text box. Then the cmdOK_Click procedure ends, and
the userform waits for more input. It can repeat the same
test-and-response over and over, until the user finally enters
something or clicks the Cancel button.

Of course, the If statement can be much more complex, such as using
the text as the key in a database query to verify that the record
exists, or checking that the text has the proper length and characters
to be a serial number.

When the demoMain macro gets control after the Me.Hide, the userform
is still in memory even though it's been removed from the screen. It
can refer to any of the items in the userform; for example, it can
look at what's in the textbox by inserting a line like this between
the .Show statement and the Nothing assignment:

userResponse = UFcopy.textInput.Text

Now the user's response is in a string variable in the macro and you
can do something with it, such as inserting it into the document.
After you do the Nothing assignment, the userform and all its contents
are wiped out. The userResponse string, though, will keep its assigned
value.

This validation is not the same idea as a modal form. Word's userforms
are modal by default, which just means that the user can't interact
with any other part of Word as long as the userform has the focus. You
can specify in the .Show statement that you want a nonmodal userform
(by including the optional parameter Modal:=False), which means that
the user can click into the document, move the insertion point, and
edit the document while the userform continues to be displayed (the
built-in Find dialog works like this.)

Karl's other point is that you should _not_ declare variables at the
top of a module or userform code, unless you specifically mean them to
be available to all procedures in that module or form. The usual
method is to declare a variable inside a procedure, so that it belongs
only to that procedure. The concern is that if you make a variable
available throughout the module, then it's too easy to change its
value when you don't mean to -- if you use the same name in two widely
separated places for different purposes, VBA thinks they're the same
variable, and that leads to bugs. Module-wide or "global" variables
should be kept to an absolute minimum.

--
Regards,
Jay Freedman
Microsoft Word MVP
Email cannot be acknowledged; please post all follow-ups to the
newsgroup so all may benefit.

In general, the goal is to reduce exposure as much as possible. So, variables that
aren't needed throughout the module should be declared at teh procedure level.
Those needed in multiple procedures would be declared at the module-level (up top).
Click to expand...

So does this mean this: in a module (and I assume in the code related
to a form) if I put all decalariations at the top of the module are
they always evaluated first prior to any code being exceuted? And can
you explain what you mean by "exposure" please.
Hide it when Cancel is pressed. Hide it when Okay is pressed *if* valid data has
been offered. If the data are invalid, spit at the user and refuse to budge. <g>
Click to expand...

Unless I'm being stupid I don't understand. I am hiding & unloading
and as I understand it I should also set the form to nothing to ensure
that it is removed from memory, this is when eithe everything os OK or
Cancel or Close is invoked. But if the data entered is invalid I need
to understand how to "spit at the user", how does it work? If the form
is already displayed does it stay loaded and can I make it "modal" as
in Access so that comntrol stays with it untill it is either completed
or cancelled? So if the code has done the "check if valid" and found
the data to be invalid if I exit the procedure is control back with
the user? Sorry to be so dumb, but this is 3 days of learning very
fast!!!
Click to expand...
 
L

liz

Liz,

Let's start with how the userform is called. Say you've created a
userform definition and named it InputUF. (You should always rename
forms from the default UserForm1 to something informative.) Then in a
module, you'll write a macro -- maybe AutoNew or AutoOpen, or
something else, which I'll call demoMain -- to start the userform. VBA
will let you do that by writing the single line

InputUF.Show

but that's really not a good way to do it. Instead, consider the
userform definition to be a "template" or "cookie cutter" for making
new userforms. This code uses the New statement to make a copy of the
InputUF definition, runs the copy with the Show statement, and
destroys the copy by setting it to Nothing.

Sub demoMain()
Dim UFcopy As InputUF
Set UFcopy = New InputUF
UFcopy.Show
Set UFcopy = Nothing
End Sub

In the userform's code, when you call Me.Hide to remove the userform
from the screen, execution resumes in the demoMain macro at the line
after the .Show statement. Until you call Me.Hide, though, the
userform stays on the screen and has the input focus.

Now, here's how this works for validating input. Let's say the
userform is very simple, just a text box named textInput, an OK button
named cmdOK, and a Cancel button named cmdCancel. In the code of the
userform, besides whatever other procedures you have -- such as
Userform_Initialize -- you'll have click procedures for the two
buttons. This example shows only how to make sure there is something
in the text box.

Private Sub cmdCancel_Click()
Me.Hide
End Sub

Private Sub cmdOK_Click()
If Len(Trim(textInput.Text)) > 0 Then
' there is something other than blanks
Me.Hide
Else
' the box is empty or blanks
MsgBox "Please enter text"
textInput.SetFocus
End If
End Sub

The If statement tests whether the text in the box, not counting any
blank characters, is at least one character long. If it is, then the
Me.Hide runs and execution goes back to the demoMain macro. If the box
is empty or contains only blanks, the user is shown a message (what
Karl meant by "spit at the user") and the cursor is moved from the OK
button back to the text box. Then the cmdOK_Click procedure ends, and
the userform waits for more input. It can repeat the same
test-and-response over and over, until the user finally enters
something or clicks the Cancel button.

Of course, the If statement can be much more complex, such as using
the text as the key in a database query to verify that the record
exists, or checking that the text has the proper length and characters
to be a serial number.

When the demoMain macro gets control after the Me.Hide, the userform
is still in memory even though it's been removed from the screen. It
can refer to any of the items in the userform; for example, it can
look at what's in the textbox by inserting a line like this between
the .Show statement and the Nothing assignment:

userResponse = UFcopy.textInput.Text

Now the user's response is in a string variable in the macro and you
can do something with it, such as inserting it into the document.
After you do the Nothing assignment, the userform and all its contents
are wiped out. The userResponse string, though, will keep its assigned
value.

This validation is not the same idea as a modal form. Word's userforms
are modal by default, which just means that the user can't interact
with any other part of Word as long as the userform has the focus. You
can specify in the .Show statement that you want a nonmodal userform
(by including the optional parameter Modal:=False), which means that
the user can click into the document, move the insertion point, and
edit the document while the userform continues to be displayed (the
built-in Find dialog works like this.)

Karl's other point is that you should _not_ declare variables at the
top of a module or userform code, unless you specifically mean them to
be available to all procedures in that module or form. The usual
method is to declare a variable inside a procedure, so that it belongs
only to that procedure. The concern is that if you make a variable
available throughout the module, then it's too easy to change its
value when you don't mean to -- if you use the same name in two widely
separated places for different purposes, VBA thinks they're the same
variable, and that leads to bugs. Module-wide or "global" variables
should be kept to an absolute minimum.

--
Regards,
Jay Freedman
Microsoft Word MVP FAQ:http://word.mvps.org
Email cannot be acknowledged; please post all follow-ups to the
newsgroup so all may benefit.

So does this mean this: in a module (and I assume in the code related
to a form) if I put all decalariations at the top of the module are
they always evaluated first prior to any code being exceuted? And can
you explain what you mean by "exposure" please.
Click to expand...
Unless I'm being stupid I don't understand. I am hiding & unloading
and as I understand it I should also set the form to nothing to ensure
that it is removed from memory, this is when eithe everything os OK or
Cancel or Close is invoked. But if the data entered is invalid I need
to understand how to "spit at the user", how does it work? If the form
is already displayed does it stay loaded and can I make it "modal" as
in Access so that comntrol stays with it untill it is either completed
or cancelled? So if the code has done the "check if valid" and found
the data to be invalid if I exit the procedure is control back with
the user? Sorry to be so dumb, but this is 3 days of learning very
fast!!!
Click to expand...
Click to expand...

Jay,

This is very helpful thank you so much! I have a couple of small
questions:

1. This code:

Sub demoMain()
Dim UFcopy As InputUF
Set UFcopy = New InputUF
UFcopy.Show
Set UFcopy = Nothing
End Sub

This form is used with word, intellisense doesn'y show "InputUF" but
does have UserForm, is this what I should use?
And intellisense doesn't show anything like "InputUF" after I enter
New, what should I do?

2. So it seems I don't need to use unload at all? in the form code I
use Hide and in the main module I use =nothing to clear memory. In
which case when would unload be used?

Otherwise I understand.

luca
 
L

liz

Liz,

Let's start with how the userform is called. Say you've created a
userform definition and named it InputUF. (You should always rename
forms from the default UserForm1 to something informative.) Then in a
module, you'll write a macro -- maybe AutoNew or AutoOpen, or
something else, which I'll call demoMain -- to start the userform. VBA
will let you do that by writing the single line

InputUF.Show

but that's really not a good way to do it. Instead, consider the
userform definition to be a "template" or "cookie cutter" for making
new userforms. This code uses the New statement to make a copy of the
InputUF definition, runs the copy with the Show statement, and
destroys the copy by setting it to Nothing.

Sub demoMain()
Dim UFcopy As InputUF
Set UFcopy = New InputUF
UFcopy.Show
Set UFcopy = Nothing
End Sub

In the userform's code, when you call Me.Hide to remove the userform
from the screen, execution resumes in the demoMain macro at the line
after the .Show statement. Until you call Me.Hide, though, the
userform stays on the screen and has the input focus.

Now, here's how this works for validating input. Let's say the
userform is very simple, just a text box named textInput, an OK button
named cmdOK, and a Cancel button named cmdCancel. In the code of the
userform, besides whatever other procedures you have -- such as
Userform_Initialize -- you'll have click procedures for the two
buttons. This example shows only how to make sure there is something
in the text box.

Private Sub cmdCancel_Click()
Me.Hide
End Sub

Private Sub cmdOK_Click()
If Len(Trim(textInput.Text)) > 0 Then
' there is something other than blanks
Me.Hide
Else
' the box is empty or blanks
MsgBox "Please enter text"
textInput.SetFocus
End If
End Sub

The If statement tests whether the text in the box, not counting any
blank characters, is at least one character long. If it is, then the
Me.Hide runs and execution goes back to the demoMain macro. If the box
is empty or contains only blanks, the user is shown a message (what
Karl meant by "spit at the user") and the cursor is moved from the OK
button back to the text box. Then the cmdOK_Click procedure ends, and
the userform waits for more input. It can repeat the same
test-and-response over and over, until the user finally enters
something or clicks the Cancel button.

Of course, the If statement can be much more complex, such as using
the text as the key in a database query to verify that the record
exists, or checking that the text has the proper length and characters
to be a serial number.

When the demoMain macro gets control after the Me.Hide, the userform
is still in memory even though it's been removed from the screen. It
can refer to any of the items in the userform; for example, it can
look at what's in the textbox by inserting a line like this between
the .Show statement and the Nothing assignment:

userResponse = UFcopy.textInput.Text

Now the user's response is in a string variable in the macro and you
can do something with it, such as inserting it into the document.
After you do the Nothing assignment, the userform and all its contents
are wiped out. The userResponse string, though, will keep its assigned
value.

This validation is not the same idea as a modal form. Word's userforms
are modal by default, which just means that the user can't interact
with any other part of Word as long as the userform has the focus. You
can specify in the .Show statement that you want a nonmodal userform
(by including the optional parameter Modal:=False), which means that
the user can click into the document, move the insertion point, and
edit the document while the userform continues to be displayed (the
built-in Find dialog works like this.)

Karl's other point is that you should _not_ declare variables at the
top of a module or userform code, unless you specifically mean them to
be available to all procedures in that module or form. The usual
method is to declare a variable inside a procedure, so that it belongs
only to that procedure. The concern is that if you make a variable
available throughout the module, then it's too easy to change its
value when you don't mean to -- if you use the same name in two widely
separated places for different purposes, VBA thinks they're the same
variable, and that leads to bugs. Module-wide or "global" variables
should be kept to an absolute minimum.

--
Regards,
Jay Freedman
Microsoft Word MVP FAQ:http://word.mvps.org
Email cannot be acknowledged; please post all follow-ups to the
newsgroup so all may benefit.

So does this mean this: in a module (and I assume in the code related
to a form) if I put all decalariations at the top of the module are
they always evaluated first prior to any code being exceuted? And can
you explain what you mean by "exposure" please.
Click to expand...
Unless I'm being stupid I don't understand. I am hiding & unloading
and as I understand it I should also set the form to nothing to ensure
that it is removed from memory, this is when eithe everything os OK or
Cancel or Close is invoked. But if the data entered is invalid I need
to understand how to "spit at the user", how does it work? If the form
is already displayed does it stay loaded and can I make it "modal" as
in Access so that comntrol stays with it untill it is either completed
or cancelled? So if the code has done the "check if valid" and found
the data to be invalid if I exit the procedure is control back with
the user? Sorry to be so dumb, but this is 3 days of learning very
fast!!!
Click to expand...
Click to expand...

Jay, one more thing...

Ii seems that I can test the form fileds directly and do not have to
declare them, is that right or have I misunderstood?

luca
 
L

liz

Liz,

Let's start with how the userform is called. Say you've created a
userform definition and named it InputUF. (You should always rename
forms from the default UserForm1 to something informative.) Then in a
module, you'll write a macro -- maybe AutoNew or AutoOpen, or
something else, which I'll call demoMain -- to start the userform. VBA
will let you do that by writing the single line

InputUF.Show

but that's really not a good way to do it. Instead, consider the
userform definition to be a "template" or "cookie cutter" for making
new userforms. This code uses the New statement to make a copy of the
InputUF definition, runs the copy with the Show statement, and
destroys the copy by setting it to Nothing.

Sub demoMain()
Dim UFcopy As InputUF
Set UFcopy = New InputUF
UFcopy.Show
Set UFcopy = Nothing
End Sub

In the userform's code, when you call Me.Hide to remove the userform
from the screen, execution resumes in the demoMain macro at the line
after the .Show statement. Until you call Me.Hide, though, the
userform stays on the screen and has the input focus.

Now, here's how this works for validating input. Let's say the
userform is very simple, just a text box named textInput, an OK button
named cmdOK, and a Cancel button named cmdCancel. In the code of the
userform, besides whatever other procedures you have -- such as
Userform_Initialize -- you'll have click procedures for the two
buttons. This example shows only how to make sure there is something
in the text box.

Private Sub cmdCancel_Click()
Me.Hide
End Sub

Private Sub cmdOK_Click()
If Len(Trim(textInput.Text)) > 0 Then
' there is something other than blanks
Me.Hide
Else
' the box is empty or blanks
MsgBox "Please enter text"
textInput.SetFocus
End If
End Sub

The If statement tests whether the text in the box, not counting any
blank characters, is at least one character long. If it is, then the
Me.Hide runs and execution goes back to the demoMain macro. If the box
is empty or contains only blanks, the user is shown a message (what
Karl meant by "spit at the user") and the cursor is moved from the OK
button back to the text box. Then the cmdOK_Click procedure ends, and
the userform waits for more input. It can repeat the same
test-and-response over and over, until the user finally enters
something or clicks the Cancel button.

Of course, the If statement can be much more complex, such as using
the text as the key in a database query to verify that the record
exists, or checking that the text has the proper length and characters
to be a serial number.

When the demoMain macro gets control after the Me.Hide, the userform
is still in memory even though it's been removed from the screen. It
can refer to any of the items in the userform; for example, it can
look at what's in the textbox by inserting a line like this between
the .Show statement and the Nothing assignment:

userResponse = UFcopy.textInput.Text

Now the user's response is in a string variable in the macro and you
can do something with it, such as inserting it into the document.
After you do the Nothing assignment, the userform and all its contents
are wiped out. The userResponse string, though, will keep its assigned
value.

This validation is not the same idea as a modal form. Word's userforms
are modal by default, which just means that the user can't interact
with any other part of Word as long as the userform has the focus. You
can specify in the .Show statement that you want a nonmodal userform
(by including the optional parameter Modal:=False), which means that
the user can click into the document, move the insertion point, and
edit the document while the userform continues to be displayed (the
built-in Find dialog works like this.)

Karl's other point is that you should _not_ declare variables at the
top of a module or userform code, unless you specifically mean them to
be available to all procedures in that module or form. The usual
method is to declare a variable inside a procedure, so that it belongs
only to that procedure. The concern is that if you make a variable
available throughout the module, then it's too easy to change its
value when you don't mean to -- if you use the same name in two widely
separated places for different purposes, VBA thinks they're the same
variable, and that leads to bugs. Module-wide or "global" variables
should be kept to an absolute minimum.

--
Regards,
Jay Freedman
Microsoft Word MVP FAQ:http://word.mvps.org
Email cannot be acknowledged; please post all follow-ups to the
newsgroup so all may benefit.

So does this mean this: in a module (and I assume in the code related
to a form) if I put all decalariations at the top of the module are
they always evaluated first prior to any code being exceuted? And can
you explain what you mean by "exposure" please.
Click to expand...
Unless I'm being stupid I don't understand. I am hiding & unloading
and as I understand it I should also set the form to nothing to ensure
that it is removed from memory, this is when eithe everything os OK or
Cancel or Close is invoked. But if the data entered is invalid I need
to understand how to "spit at the user", how does it work? If the form
is already displayed does it stay loaded and can I make it "modal" as
in Access so that comntrol stays with it untill it is either completed
or cancelled? So if the code has done the "check if valid" and found
the data to be invalid if I exit the procedure is control back with
the user? Sorry to be so dumb, but this is 3 days of learning very
fast!!!
Click to expand...
Click to expand...

Jay, one more thing...

It seems that I can use the form fields directly & don't have to
declare them, is this correct?

luca
 
J

Jay Freedman

Jay,

This is very helpful thank you so much! I have a couple of small
questions:

1. This code:

Sub demoMain()
Dim UFcopy As InputUF
Set UFcopy = New InputUF
UFcopy.Show
Set UFcopy = Nothing
End Sub

This form is used with word, intellisense doesn'y show "InputUF" but
does have UserForm, is this what I should use?
And intellisense doesn't show anything like "InputUF" after I enter
New, what should I do?
Click to expand...

You have to create your userform definition first. When you use the
Insert > Userform command in the VBA editor, Word names the new form
UserForm1. In the Properties pane (View > Properties of F4), change
the name to something informative. I chose InputUF. If you choose
another name, use that other name in the macro. The name will appear
in IntelliSense _after_ you define it.
2. So it seems I don't need to use unload at all? in the form code I
use Hide and in the main module I use =nothing to clear memory. In
which case when would unload be used?
Click to expand...

That's correct -- Unload is needed only if you use the UserForm1.Show
method that I told you not to use.
Otherwise I understand.

luca
Click to expand...

--
Regards,
Jay Freedman
Microsoft Word MVP
Email cannot be acknowledged; please post all follow-ups to the
newsgroup so all may benefit.
 
L

liz

Liz,

Let's start with how the userform is called. Say you've created a
userform definition and named it InputUF. (You should always rename
forms from the default UserForm1 to something informative.) Then in a
module, you'll write a macro -- maybe AutoNew or AutoOpen, or
something else, which I'll call demoMain -- to start the userform. VBA
will let you do that by writing the single line

InputUF.Show

but that's really not a good way to do it. Instead, consider the
userform definition to be a "template" or "cookie cutter" for making
new userforms. This code uses the New statement to make a copy of the
InputUF definition, runs the copy with the Show statement, and
destroys the copy by setting it to Nothing.

Sub demoMain()
Dim UFcopy As InputUF
Set UFcopy = New InputUF
UFcopy.Show
Set UFcopy = Nothing
End Sub

In the userform's code, when you call Me.Hide to remove the userform
from the screen, execution resumes in the demoMain macro at the line
after the .Show statement. Until you call Me.Hide, though, the
userform stays on the screen and has the input focus.

Now, here's how this works for validating input. Let's say the
userform is very simple, just a text box named textInput, an OK button
named cmdOK, and a Cancel button named cmdCancel. In the code of the
userform, besides whatever other procedures you have -- such as
Userform_Initialize -- you'll have click procedures for the two
buttons. This example shows only how to make sure there is something
in the text box.

Private Sub cmdCancel_Click()
Me.Hide
End Sub

Private Sub cmdOK_Click()
If Len(Trim(textInput.Text)) > 0 Then
' there is something other than blanks
Me.Hide
Else
' the box is empty or blanks
MsgBox "Please enter text"
textInput.SetFocus
End If
End Sub

The If statement tests whether the text in the box, not counting any
blank characters, is at least one character long. If it is, then the
Me.Hide runs and execution goes back to the demoMain macro. If the box
is empty or contains only blanks, the user is shown a message (what
Karl meant by "spit at the user") and the cursor is moved from the OK
button back to the text box. Then the cmdOK_Click procedure ends, and
the userform waits for more input. It can repeat the same
test-and-response over and over, until the user finally enters
something or clicks the Cancel button.

Of course, the If statement can be much more complex, such as using
the text as the key in a database query to verify that the record
exists, or checking that the text has the proper length and characters
to be a serial number.

When the demoMain macro gets control after the Me.Hide, the userform
is still in memory even though it's been removed from the screen. It
can refer to any of the items in the userform; for example, it can
look at what's in the textbox by inserting a line like this between
the .Show statement and the Nothing assignment:

userResponse = UFcopy.textInput.Text

Now the user's response is in a string variable in the macro and you
can do something with it, such as inserting it into the document.
After you do the Nothing assignment, the userform and all its contents
are wiped out. The userResponse string, though, will keep its assigned
value.

This validation is not the same idea as a modal form. Word's userforms
are modal by default, which just means that the user can't interact
with any other part of Word as long as the userform has the focus. You
can specify in the .Show statement that you want a nonmodal userform
(by including the optional parameter Modal:=False), which means that
the user can click into the document, move the insertion point, and
edit the document while the userform continues to be displayed (the
built-in Find dialog works like this.)

Karl's other point is that you should _not_ declare variables at the
top of a module or userform code, unless you specifically mean them to
be available to all procedures in that module or form. The usual
method is to declare a variable inside a procedure, so that it belongs
only to that procedure. The concern is that if you make a variable
available throughout the module, then it's too easy to change its
value when you don't mean to -- if you use the same name in two widely
separated places for different purposes, VBA thinks they're the same
variable, and that leads to bugs. Module-wide or "global" variables
should be kept to an absolute minimum.

--
Regards,
Jay Freedman
Microsoft Word MVP FAQ:http://word.mvps.org
Email cannot be acknowledged; please post all follow-ups to the
newsgroup so all may benefit.

So does this mean this: in a module (and I assume in the code related
to a form) if I put all decalariations at the top of the module are
they always evaluated first prior to any code being exceuted? And can
you explain what you mean by "exposure" please.
Click to expand...
Unless I'm being stupid I don't understand. I am hiding & unloading
and as I understand it I should also set the form to nothing to ensure
that it is removed from memory, this is when eithe everything os OK or
Cancel or Close is invoked. But if the data entered is invalid I need
to understand how to "spit at the user", how does it work? If the form
is already displayed does it stay loaded and can I make it "modal" as
in Access so that comntrol stays with it untill it is either completed
or cancelled? So if the code has done the "check if valid" and found
the data to be invalid if I exit the procedure is control back with
the user? Sorry to be so dumb, but this is 3 days of learning very
fast!!!
Click to expand...
Click to expand...

This is very helpful thank you so much! I have a question:

So it seems I don't need to use unload at all? in the form code I
use Hide and in the main module I use =nothing to clear memory. In
which case when would unload be used?
 
J

Jay Freedman

Jay, one more thing...

Ii seems that I can test the form fileds directly and do not have to
declare them, is that right or have I misunderstood?

luca
Click to expand...

That's correct. The fields are declared behind-the-scenes when you
insert them on the userform, and they are then properties of the
userform. That's why, in the macro, you can address

UFcopy.TextBox1.Text

where UFcopy is the name of the userform created by the New statement.
In the code of the userform, you don't have to state the name of the
userform -- it's implied. In the userform code you could also use the
syntax

Me.TextBox1.Text

The keyword Me always refers to the current running userform. This is
very useful when a single macro might launch two or more copies of the
same userform definition.

--
Regards,
Jay Freedman
Microsoft Word MVP
Email cannot be acknowledged; please post all follow-ups to the
newsgroup so all may benefit.
 
L

liz

That's correct. The fields are declared behind-the-scenes when you
insert them on the userform, and they are then properties of the
userform. That's why, in the macro, you can address

UFcopy.TextBox1.Text

where UFcopy is the name of the userform created by the New statement.
In the code of the userform, you don't have to state the name of the
userform -- it's implied. In the userform code you could also use the
syntax

Me.TextBox1.Text

The keyword Me always refers to the current running userform. This is
very useful when a single macro might launch two or more copies of the
same userform definition.

--
Regards,
Jay Freedman
Microsoft Word MVP FAQ:http://word.mvps.org
Email cannot be acknowledged; please post all follow-ups to the
newsgroup so all may benefit.
Click to expand...

Very helpful, I feel like I'm starting to toddle rather than crawl as
a VBA baby! thank you
 
K

Karl E. Peterson

So does this mean this: in a module (and I assume in the code related
to a form) if I put all decalariations at the top of the module are
they always evaluated first prior to any code being exceuted? And can
you explain what you mean by "exposure" please.
Click to expand...

Declarations aren't necessarily "evaluated", to be precise. But if they're up-top,
they are considered to be "exposed" to the entire module (form, class, or standard).
That is, any routine anywhere in that module can read and modify them. To get even
a bit more pedantic, what you need to do is get in strict habit of declaring these
"Module-level" variables either Public or Private. That will determine whether
they're only visible to the current module (private) or to the entire application
(public).
Unless I'm being stupid I don't understand.
Click to expand...

Looks like Jay got ya going there?
to understand how to "spit at the user", how does it work?
Click to expand...

Technically speaking <g>, this would be something along the lines of:

' the box is empty or blanks
MsgBox "Please enter text"
textInput.SetFocus

A great number of UI designers consider this to be roughly the equivalent of
spitting at the user. Seriously rude. /"Not that that's a bad thing!"/ Google
"Alan Cooper" and msgbox sometime. :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Declaring Variables 3
Data entry to table from a form 0
Data Entry VBA 4
Data entry VBA 1
Data entry for a table from a form 2
Data entry for a table from a form 1
Error with declaration 3
Populating checkboxes from saved values 3

Top