Restrict input to an input box to numerical format

[Greg Maxey]

Hi,

Sorry if this subject appears twice. I had an problem with OE and it
doesn't appear that my first attempt passed through:


Can you restrict the format of input box input to a numerical format? How
would that be coded? If not, is there a way to cause a error message box to
appear if the input is not numerical?

thanks.

 

[Peter Hewett]

Hi Greg Maxey

Do you mean a UserForm TextBox control? If so you can use:

If IsNumeric(TextBox.Value) Then
' It's numeric
Else
' it's not numeric
EndIf

If you mead a FormField then you can just set it's "Type" to "Number"

HTH + Cheers - Peter

 

[Doug Robbins - Word MVP]

Hi Greg,

You can do the same as Peter suggested with an InputBox as well

If IsNumeric(InputBox("Enter a Number", "Numbers Only", 0)) Then
MsgBox "Number entered"
Else
MsgBox "You did not Enter a Number."
End If


--
Please post any further questions or followup to the newsgroups for the
benefit of others who may be interested. Unsolicited questions forwarded
directly to me will only be answered on a paid consulting basis.

Hope this helps
Doug Robbins - Word MVP

 

[Greg Maxey]

Doug, Peter

Thank you both.

Sorry, but I am still confused. Here is what I have right now in an AutoNew
macro:

DCA = InputBox("Enter District Record Credits Attempted", "DCA", "0.00")

How would I apply your code to evaluate the result and if it is not a number
then display a message that a number must be entered and then loop back to
the Inputbox?

Is this possible?

It is late here and I may not be able to get back to you tonight. Thanks

 

[Jean-Guy Marcil]

Bonjour,

Dans son message, notre ami < Greg Maxey > nous laissait savoir que :
In this message, our friend < Greg Maxey > informed us that:


|| Hi,
||
|| Sorry if this subject appears twice. I had an problem with OE and it
|| doesn't appear that my first attempt passed through:
||
||
|| Can you restrict the format of input box input to a numerical format?
How
|| would that be coded? If not, is there a way to cause a error message box
to
|| appear if the input is not numerical?
||
|| thanks.
||

To add to Doug's idea, if you really want to force the user to generate a
number, you can try something like:

'_______________________________________
Dim MyMessage As String
Dim BoxTitle As String
Dim BoxDefault As String
Dim MyNumber As String

MyMessage = "Enter a Number"
BoxTitle = "Numbers Only"
BoxDefault = "0"

TryAgain:
MyNumber = InputBox(MyMessage, BoxTitle, BoxDefault)

If Not IsNumeric(MyNumber) Then
MsgBox "You did not Enter a Number."
GoTo TryAgain
Else
MsgBox "Number entered."
'Do something with MyNumber
End If
'_______________________________________

HTH

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[Greg Maxey]

Doug, Peter, JGM

I have put together the following snipet of code that seems to work. If it
needs refinement, please advise:

EnterNumber:
QP = InputBox("Enter student's Record Quality Points", "QP", "0.00")
If IsNumeric(QP) Then
GoTo Next
Else
MsgBox "You must input a number."
GoTo EnterNumber
End If
Next:

Thanks.

 

[Greg Maxey]

JGM,

I see the advantage of the IF Not IsNumeric function for my purposes.
Revised as follows:

EnterQPNumber:
QP = InputBox("Enter student's Record Quality Points", "Quality Points",
"0.00")
If Not IsNumeric(QP) Then
MsgBox "You must enter a valid number."
GoTo EnterQPNumber
End If

Thanks JGM, Doug and Peter.

 

[Peter Hewett]

Hi Greg Maxey

GoTo's are frowned upon! Here's a structure variant:

Public Sub MustBeNumeric()
Dim strQP As String
Dim boolBad As Boolean

Do
strQP = InputBox("Enter student's Record Quality Points", _
"Quality Points", "0.00")
boolBad = Not IsNumeric(strQP)
If boolBad Then
MsgBox "You must enter a valid number."
End If
Loop While boolBad
End Sub

Cheers - Peter

JGM,

I see the advantage of the IF Not IsNumeric function for my purposes.
Revised as follows:

EnterQPNumber:
QP = InputBox("Enter student's Record Quality Points", "Quality Points",
"0.00")
If Not IsNumeric(QP) Then
MsgBox "You must enter a valid number."
GoTo EnterQPNumber
End If

Thanks JGM, Doug and Peter.



--
Greg Maxey
A peer in "peer to peer" support
Rockledge, FL
To e-mail, edit out the "w...spam" in (e-mail address removed)

HTH + Cheers - Peter

 

[Jean-Guy Marcil]

Bonjour,

Dans son message, notre ami < Peter Hewett > nous laissait savoir que :
In this message, our friend < Peter Hewett > informed us that:


|| Hi Greg Maxey
||
|| GoTo's are frowned upon! Here's a structure variant:

Not being a professional programmer by training, I was wondering why GoTo
were frowned upon.... Is it because they are less elegant than other
methods? Too easy? Prone to errors? Slower? I see GoTo all the time with
error handlers... Are GoTo reserved for those cases?

Just curious!

TIA

||
|| Public Sub MustBeNumeric()
|| Dim strQP As String
|| Dim boolBad As Boolean
||
|| Do
|| strQP = InputBox("Enter student's Record Quality Points", _
|| "Quality Points", "0.00")
|| boolBad = Not IsNumeric(strQP)
|| If boolBad Then
|| MsgBox "You must enter a valid number."
|| End If
|| Loop While boolBad
|| End Sub
||
|| Cheers - Peter
||
|| "Greg Maxey" <[email protected]>, said:
||
||| JGM,
|||
||| I see the advantage of the IF Not IsNumeric function for my purposes.
||| Revised as follows:
|||
||| EnterQPNumber:
||| QP = InputBox("Enter student's Record Quality Points", "Quality
Points",
||| "0.00")
||| If Not IsNumeric(QP) Then
||| MsgBox "You must enter a valid number."
||| GoTo EnterQPNumber
||| End If
|||
||| Thanks JGM, Doug and Peter.
|||
|||
|||
||| --
||| Greg Maxey
||| A peer in "peer to peer" support
||| Rockledge, FL
||| To e-mail, edit out the "w...spam" in (e-mail address removed)
|||
||| Jean-Guy Marcil wrote:
|||| Bonjour,
||||
|||| Dans son message, notre ami < Greg Maxey > nous laissait savoir que :
|||| In this message, our friend < Greg Maxey > informed us that:
||||
||||
|||||| Hi,
||||||
|||||| Sorry if this subject appears twice. I had an problem with OE and
|||||| it doesn't appear that my first attempt passed through:
||||||
||||||
|||||| Can you restrict the format of input box input to a numerical
|||||| format?
|||| How
|||||| would that be coded? If not, is there a way to cause a error
|||||| message box to appear if the input is not numerical?
||||||
|||||| thanks.
||||||
||||
|||| To add to Doug's idea, if you really want to force the user to
|||| generate a number, you can try something like:
||||
|||| '_______________________________________
|||| Dim MyMessage As String
|||| Dim BoxTitle As String
|||| Dim BoxDefault As String
|||| Dim MyNumber As String
||||
|||| MyMessage = "Enter a Number"
|||| BoxTitle = "Numbers Only"
|||| BoxDefault = "0"
||||
|||| TryAgain:
|||| MyNumber = InputBox(MyMessage, BoxTitle, BoxDefault)
||||
|||| If Not IsNumeric(MyNumber) Then
|||| MsgBox "You did not Enter a Number."
|||| GoTo TryAgain
|||| Else
|||| MsgBox "Number entered."
|||| 'Do something with MyNumber
|||| End If
|||| '_______________________________________
||||
|||| HTH
|||
||
|| HTH + Cheers - Peter

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[Peter Hewett]

Hi Jean-Guy Marcil

GoTo's are really a hang over from pre block structured code days. With the
exception of error handlers in VB/VBA where you don't have a choice and have to
use a very specific form of GoTo. They are actively discourage as they cause
branches in the logic break the block structure. Add more than a couple to your
code and you end up with spaghetti, just like in the good old days! Even the
online help discourages their use.

VB.Net implements block structured error handling with Try/Catch/Finally/End
Try.

HTH + Cheers - Peter

 

[Jean-Guy Marcil]

Bonjour,

Dans son message, notre ami < Peter Hewett > nous laissait savoir que :
In this message, our friend < Peter Hewett > informed us that:


|| Hi Jean-Guy Marcil
||
|| GoTo's are really a hang over from pre block structured code days. With
the
|| exception of error handlers in VB/VBA where you don't have a choice and
have to
|| use a very specific form of GoTo. They are actively discourage as they
cause
|| branches in the logic break the block structure. Add more than a couple
to your
|| code and you end up with spaghetti, just like in the good old days! Even
the
|| online help discourages their use.
||
|| VB.Net implements block structured error handling with
Try/Catch/Finally/End
|| Try.


Ok, I see, they are frowned upon because if they are overused they can cause
nightmares when trying to maintain code.
I guess that if you only use it here and there, there's no harm, but I can
see the problems if you start branching out all over the place with a bunch
of them.

Can I bother you with another question then?
Very often you have a fairly long module containing a lot of user or
document interaction. Depending on the user input or the conditions found in
the document, you want your code to skip certain parts of the module.
Without using GoTo, how do you get the code to jump over certain parts if
they do not apply? Is it better in such a situation to break the module
apart in a bunch of little modules and call each smaller module as
appropriate... or are there other ways of handling this?

Thanks.

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[Charles Kenyon]

Rather than a GoTo to skip, you could use an IF structure to include.
--

Charles Kenyon

See the MVP FAQ: <URL: http://www.mvps.org/word/> which is awesome!
--------- --------- --------- --------- --------- ---------
This message is posted to a newsgroup. Please post replies
and questions to the newsgroup so that others can learn
from my ignorance and your wisdom.

 

[Peter Hewett]

Hi Jean-Guy Marcil

There are a number of techniques to get around this problem. Modularisation is
one of them and just plain good programming practice. By 'modularisation" I
mean break the code down in sub procedures or even better yet class modules.
Each procedure should be relatively short, this is an arbitrary value judgement
call. I use something in the order of 60-100 lines max per procedure. Normally
much shorter. I don't worry about the amount of code in standard module, I just
use them for functional grouping. Likewise with class or UserForm modules I
tend to keep all code that relates to the class in one module rather than spread
it over multiple modules.

Within each procedure use block structure and indentation to make the code as
readable as possible. To skip certain parts you can use If/Then/Else/EndIf. If
you need to test for the same condition more than once and the test is expensive
declare and use a temporary variable. VB/VBA creates invisible temporary
variables anyway, so you might as well declare and use your own! The code may
be a tad more verbose (like me!) but it's more efficient. Also use With blocks
where you can. Since a With block only provides a shortcut to one object, I
often assign other expensive object references to a temporary variable for use
within the With block if I refer to it more than once or twice.

By expensive i mean it drills down through a number of objects as in:
ActiveDocument.Range.ParagraphFormat.Borders.InsideColor

Every time you use a dot operator in an object reference VB/VBA creates a
temporary variable! If your using COM then every dot operation is a COM call
(high overhead stuff).

I write a "lot" of code and apart from "On Error Goto ?" I've not used a GoTo
statement in the last 7 years. If you ever get close to a situation where you
think "GoTo" it's probably time to rethink, redesign, re-implement your code!

If you've had a chance to look at the "FormField Tab Order" add-in I emailed
you, you'll see the above put into practice.

Oh yeah, while I on my soapbox commenting your code is essential, not a nice
optional extra. On average for every 100 lines of code I write there are 40
lines of comments. It also essential to comment "why" your code is doing
something and not the "what". The "what" tends to be self evident from the code
(once you understand the language).

Cheers - Peter

Bonjour,

Dans son message, notre ami < Peter Hewett > nous laissait savoir que :
In this message, our friend < Peter Hewett > informed us that:


|| Hi Jean-Guy Marcil
||
|| GoTo's are really a hang over from pre block structured code days. With
the
|| exception of error handlers in VB/VBA where you don't have a choice and
have to
|| use a very specific form of GoTo. They are actively discourage as they
cause
|| branches in the logic break the block structure. Add more than a couple
to your
|| code and you end up with spaghetti, just like in the good old days! Even
the
|| online help discourages their use.
||
|| VB.Net implements block structured error handling with
Try/Catch/Finally/End
|| Try.


Ok, I see, they are frowned upon because if they are overused they can cause
nightmares when trying to maintain code.
I guess that if you only use it here and there, there's no harm, but I can
see the problems if you start branching out all over the place with a bunch
of them.

Can I bother you with another question then?
Very often you have a fairly long module containing a lot of user or
document interaction. Depending on the user input or the conditions found in
the document, you want your code to skip certain parts of the module.
Without using GoTo, how do you get the code to jump over certain parts if
they do not apply? Is it better in such a situation to break the module
apart in a bunch of little modules and call each smaller module as
appropriate... or are there other ways of handling this?

Thanks.

HTH + Cheers - Peter

 

[Jean-Guy Marcil]

Bonjour,

Dans son message, < Peter Hewett > écrivait :
In this message, < Peter Hewett > wrote:

|| Hi Jean-Guy Marcil
||
|| There are a number of techniques to get around this problem.
Modularisation is
|| one of them and just plain good programming practice. By
'modularisation" I
|| mean break the code down in sub procedures or even better yet class
modules.
|| Each procedure should be relatively short, this is an arbitrary value
judgement
|| call. I use something in the order of 60-100 lines max per procedure.
Normally
|| much shorter. I don't worry about the amount of code in standard module,
I just
|| use them for functional grouping. Likewise with class or UserForm
modules I
|| tend to keep all code that relates to the class in one module rather than
spread
|| it over multiple modules.
||
|| Within each procedure use block structure and indentation to make the
code as
|| readable as possible. To skip certain parts you can use
If/Then/Else/EndIf. If
|| you need to test for the same condition more than once and the test is
expensive
|| declare and use a temporary variable. VB/VBA creates invisible temporary
|| variables anyway, so you might as well declare and use your own! The
code may
|| be a tad more verbose (like me!) but it's more efficient. Also use With
blocks

I like to use public Booleans that I use to test for conditions if those
conditions have repercussions in many modules or procedures... Is that a bad
habit?

|| where you can. Since a With block only provides a shortcut to one
object, I
|| often assign other expensive object references to a temporary variable
for use
|| within the With block if I refer to it more than once or twice.
||
|| By expensive i mean it drills down through a number of objects as in:
|| ActiveDocument.Range.ParagraphFormat.Borders.InsideColor
||
|| Every time you use a dot operator in an object reference VB/VBA creates a
|| temporary variable! If your using COM then every dot operation is a COM
call
|| (high overhead stuff).

Thanks for the reminder on that point... I have read this before, but tend
to forget abut it when writing code...

||
|| I write a "lot" of code and apart from "On Error Goto ?" I've not used a
GoTo
|| statement in the last 7 years. If you ever get close to a situation
where you
|| think "GoTo" it's probably time to rethink, redesign, re-implement your
code!

I agree with the general principle... I remember one particular project I
had to redesigned because of that particular problem. But I think that If
you use one GoTo as a shortcut.... it's not that bad...

||
|| If you've had a chance to look at the "FormField Tab Order" add-in I
emailed
|| you, you'll see the above put into practice.

Sorry... been busy with work and the kids lately... will get around to it
eventually! Promise!

||
|| Oh yeah, while I on my soapbox commenting your code is essential, not a
nice
|| optional extra. On average for every 100 lines of code I write there are
40
|| lines of comments. It also essential to comment "why" your code is doing
|| something and not the "what". The "what" tends to be self evident from
the code
|| (once you understand the language).

Absolutely right... I have been whackedon the side of the head by my
laziness to comment... I remember a client asking for modifications 2 years
after I wrote some code.... In those 2 years I had learned new techniques
and stuff.... So I had no idea what why I had written the code the way I
had... Had to debug step by step ... A real waste of time! But once I get
into a groove, I forget about slowing down to write comments... Have to whip
myself into shape regarding this ;-)

Thanks for taking the time!

||
|| Cheers - Peter
||
||
|| "Jean-Guy Marcil" <[email protected]>, said:
||
||| Bonjour,
|||
||| Dans son message, notre ami < Peter Hewett > nous laissait savoir que :
||| In this message, our friend < Peter Hewett > informed us that:
|||
|||
||||| Hi Jean-Guy Marcil
|||||
||||| GoTo's are really a hang over from pre block structured code days.
With the
||||| exception of error handlers in VB/VBA where you don't have a choice
and have to
||||| use a very specific form of GoTo. They are actively discourage as
they cause
||||| branches in the logic break the block structure. Add more than a
couple
||| to your
||||| code and you end up with spaghetti, just like in the good old days!
Even the
||||| online help discourages their use.
|||||
||||| VB.Net implements block structured error handling with
Try/Catch/Finally/End
||||| Try.
|||
|||
||| Ok, I see, they are frowned upon because if they are overused they can
cause
||| nightmares when trying to maintain code.
||| I guess that if you only use it here and there, there's no harm, but I
can
||| see the problems if you start branching out all over the place with a
bunch
||| of them.
|||
||| Can I bother you with another question then?
||| Very often you have a fairly long module containing a lot of user or
||| document interaction. Depending on the user input or the conditions
found in
||| the document, you want your code to skip certain parts of the module.
||| Without using GoTo, how do you get the code to jump over certain parts
if
||| they do not apply? Is it better in such a situation to break the module
||| apart in a bunch of little modules and call each smaller module as
||| appropriate... or are there other ways of handling this?
|||
||| Thanks.
||
|| HTH + Cheers - Peter

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

 

[Greg Maxey]

Peter,

Thanks. I will experiment with this.

 

[Peter Hewett]

Hi Jean-Guy Marcil

Said <I like to use public Booleans that I use to test for conditions if those
conditions have repercussions in many modules or procedures... Is that a bad
habit?>

That's one of the reasons I'm a strong proponent for class modules. If you
encapsulate stuff in a class you can often do away with Pubic flags and
implement and use a Property. I guess like most things you may just have to use
them, but I try to design out Globals and limit the maximum scope of variables
to Private.

This gets to be more of a problem with large projects, trying to work out what's
setting/clearing Public variables can be a nightmare as there are no clear
functional boundaries.

Also with procedures I always explicitly declare their scope.

Cheers - Peter

Bonjour,

Dans son message, < Peter Hewett > écrivait :
In this message, < Peter Hewett > wrote:

|| Hi Jean-Guy Marcil
||
|| There are a number of techniques to get around this problem.
Modularisation is
|| one of them and just plain good programming practice. By
'modularisation" I
|| mean break the code down in sub procedures or even better yet class
modules.
|| Each procedure should be relatively short, this is an arbitrary value
judgement
|| call. I use something in the order of 60-100 lines max per procedure.
Normally
|| much shorter. I don't worry about the amount of code in standard module,
I just
|| use them for functional grouping. Likewise with class or UserForm
modules I
|| tend to keep all code that relates to the class in one module rather than
spread
|| it over multiple modules.
||
|| Within each procedure use block structure and indentation to make the
code as
|| readable as possible. To skip certain parts you can use
If/Then/Else/EndIf. If
|| you need to test for the same condition more than once and the test is
expensive
|| declare and use a temporary variable. VB/VBA creates invisible temporary
|| variables anyway, so you might as well declare and use your own! The
code may
|| be a tad more verbose (like me!) but it's more efficient. Also use With
blocks

I like to use public Booleans that I use to test for conditions if those
conditions have repercussions in many modules or procedures... Is that a bad
habit?

|| where you can. Since a With block only provides a shortcut to one
object, I
|| often assign other expensive object references to a temporary variable
for use
|| within the With block if I refer to it more than once or twice.
||
|| By expensive i mean it drills down through a number of objects as in:
|| ActiveDocument.Range.ParagraphFormat.Borders.InsideColor
||
|| Every time you use a dot operator in an object reference VB/VBA creates a
|| temporary variable! If your using COM then every dot operation is a COM
call
|| (high overhead stuff).

Thanks for the reminder on that point... I have read this before, but tend
to forget abut it when writing code...

||
|| I write a "lot" of code and apart from "On Error Goto ?" I've not used a
GoTo
|| statement in the last 7 years. If you ever get close to a situation
where you
|| think "GoTo" it's probably time to rethink, redesign, re-implement your
code!

I agree with the general principle... I remember one particular project I
had to redesigned because of that particular problem. But I think that If
you use one GoTo as a shortcut.... it's not that bad...

||
|| If you've had a chance to look at the "FormField Tab Order" add-in I
emailed
|| you, you'll see the above put into practice.

Sorry... been busy with work and the kids lately... will get around to it
eventually! Promise!

||
|| Oh yeah, while I on my soapbox commenting your code is essential, not a
nice
|| optional extra. On average for every 100 lines of code I write there are
40
|| lines of comments. It also essential to comment "why" your code is doing
|| something and not the "what". The "what" tends to be self evident from
the code
|| (once you understand the language).

Absolutely right... I have been whackedon the side of the head by my
laziness to comment... I remember a client asking for modifications 2 years
after I wrote some code.... In those 2 years I had learned new techniques
and stuff.... So I had no idea what why I had written the code the way I
had... Had to debug step by step ... A real waste of time! But once I get
into a groove, I forget about slowing down to write comments... Have to whip
myself into shape regarding this ;-)

Thanks for taking the time!

||
|| Cheers - Peter
||
||
|| "Jean-Guy Marcil" <[email protected]>, said:
||
||| Bonjour,
|||
||| Dans son message, notre ami < Peter Hewett > nous laissait savoir que :
||| In this message, our friend < Peter Hewett > informed us that:
|||
|||
||||| Hi Jean-Guy Marcil
|||||
||||| GoTo's are really a hang over from pre block structured code days.
With the
||||| exception of error handlers in VB/VBA where you don't have a choice
and have to
||||| use a very specific form of GoTo. They are actively discourage as
they cause
||||| branches in the logic break the block structure. Add more than a
couple
||| to your
||||| code and you end up with spaghetti, just like in the good old days!
Even the
||||| online help discourages their use.
|||||
||||| VB.Net implements block structured error handling with
Try/Catch/Finally/End
||||| Try.
|||
|||
||| Ok, I see, they are frowned upon because if they are overused they can
cause
||| nightmares when trying to maintain code.
||| I guess that if you only use it here and there, there's no harm, but I
can
||| see the problems if you start branching out all over the place with a
bunch
||| of them.
|||
||| Can I bother you with another question then?
||| Very often you have a fairly long module containing a lot of user or
||| document interaction. Depending on the user input or the conditions
found in
||| the document, you want your code to skip certain parts of the module.
||| Without using GoTo, how do you get the code to jump over certain parts
if
||| they do not apply? Is it better in such a situation to break the module
||| apart in a bunch of little modules and call each smaller module as
||| appropriate... or are there other ways of handling this?
|||
||| Thanks.
||
|| HTH + Cheers - Peter

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org

HTH + Cheers - Peter

 

[Jean-Guy Marcil]

Bonjour,

Dans son message, < Peter Hewett > écrivait :
In this message, < Peter Hewett > wrote:

|| Hi Jean-Guy Marcil
||
|| Said <I like to use public Booleans that I use to test for conditions if
those
|| conditions have repercussions in many modules or procedures... Is that a
bad
|| habit?>
||
|| That's one of the reasons I'm a strong proponent for class modules. If
you
|| encapsulate stuff in a class you can often do away with Pubic flags and
|| implement and use a Property. I guess like most things you may just have
to use
|| them, but I try to design out Globals and limit the maximum scope of
variables
|| to Private.

I have to learn more about class modules... Somehow, except for a few
applications where the procedure is clearly outlined somewhere (e.g. there
are tons of examples for creating Document event in Word VBA on the net, I
can use those), I tend to shy away from them because I do not understand
them as well as I should... Any good links on learning more about class
modules?

||
|| This gets to be more of a problem with large projects, trying to work out
what's
|| setting/clearing Public variables can be a nightmare as there are no
clear
|| functional boundaries.

Totally true, I have experienced this in larger projects where I had 6 or 7
public flags... after a while you do not know what is set and where.... It
can get difficult to maintain and build upon.

TIA

||
|| Also with procedures I always explicitly declare their scope.
||
|| Cheers - Peter
||
||
|| "Jean-Guy Marcil" <[email protected]>, said:
||
||| Bonjour,
|||
||| Dans son message, < Peter Hewett > écrivait :
||| In this message, < Peter Hewett > wrote:
|||
||||| Hi Jean-Guy Marcil
|||||
||||| There are a number of techniques to get around this problem.
||| Modularisation is
||||| one of them and just plain good programming practice. By
||| 'modularisation" I
||||| mean break the code down in sub procedures or even better yet class
modules.
||||| Each procedure should be relatively short, this is an arbitrary value
judgement
||||| call. I use something in the order of 60-100 lines max per procedure.
Normally
||||| much shorter. I don't worry about the amount of code in standard
module,
||| I just
||||| use them for functional grouping. Likewise with class or UserForm
||| modules I
||||| tend to keep all code that relates to the class in one module rather
than spread
||||| it over multiple modules.
|||||
||||| Within each procedure use block structure and indentation to make the
||| code as
||||| readable as possible. To skip certain parts you can use
If/Then/Else/EndIf. If
||||| you need to test for the same condition more than once and the test is
expensive
||||| declare and use a temporary variable. VB/VBA creates invisible
temporary
||||| variables anyway, so you might as well declare and use your own! The
||| code may
||||| be a tad more verbose (like me!) but it's more efficient. Also use
With blocks
|||
||| I like to use public Booleans that I use to test for conditions if those
||| conditions have repercussions in many modules or procedures... Is that a
bad
||| habit?
|||
||||| where you can. Since a With block only provides a shortcut to one
||| object, I
||||| often assign other expensive object references to a temporary variable
||| for use
||||| within the With block if I refer to it more than once or twice.
|||||
||||| By expensive i mean it drills down through a number of objects as in:
||||| ActiveDocument.Range.ParagraphFormat.Borders.InsideColor
|||||
||||| Every time you use a dot operator in an object reference VB/VBA
creates a
||||| temporary variable! If your using COM then every dot operation is a
COM call
||||| (high overhead stuff).
|||
||| Thanks for the reminder on that point... I have read this before, but
tend
||| to forget abut it when writing code...
|||
|||||
||||| I write a "lot" of code and apart from "On Error Goto ?" I've not used
a GoTo
||||| statement in the last 7 years. If you ever get close to a situation
||| where you
||||| think "GoTo" it's probably time to rethink, redesign, re-implement
your code!
|||
||| I agree with the general principle... I remember one particular project
I
||| had to redesigned because of that particular problem. But I think that
If
||| you use one GoTo as a shortcut.... it's not that bad...
|||
|||||
||||| If you've had a chance to look at the "FormField Tab Order" add-in I
emailed
||||| you, you'll see the above put into practice.
|||
||| Sorry... been busy with work and the kids lately... will get around to
it
||| eventually! Promise!
|||
|||||
||||| Oh yeah, while I on my soapbox commenting your code is essential, not
a nice
||||| optional extra. On average for every 100 lines of code I write there
are 40
||||| lines of comments. It also essential to comment "why" your code is
doing
||||| something and not the "what". The "what" tends to be self evident
from
||| the code
||||| (once you understand the language).
|||
||| Absolutely right... I have been whackedon the side of the head by my
||| laziness to comment... I remember a client asking for modifications 2
years
||| after I wrote some code.... In those 2 years I had learned new
techniques
||| and stuff.... So I had no idea what why I had written the code the way I
||| had... Had to debug step by step ... A real waste of time! But once I
get
||| into a groove, I forget about slowing down to write comments... Have to
whip
||| myself into shape regarding this ;-)
|||
||| Thanks for taking the time!
|||
|||||
||||| Cheers - Peter
|||||
|||||
||||| "Jean-Guy Marcil" <[email protected]>, said:
|||||
|||||| Bonjour,
||||||
|||||| Dans son message, notre ami < Peter Hewett > nous laissait savoir que
:
|||||| In this message, our friend < Peter Hewett > informed us that:
||||||
||||||
|||||||| Hi Jean-Guy Marcil
||||||||
|||||||| GoTo's are really a hang over from pre block structured code days.
||| With the
|||||||| exception of error handlers in VB/VBA where you don't have a choice
||| and have to
|||||||| use a very specific form of GoTo. They are actively discourage as
||| they cause
|||||||| branches in the logic break the block structure. Add more than a
couple to your
|||||||| code and you end up with spaghetti, just like in the good old days!
||| Even the
|||||||| online help discourages their use.
||||||||
|||||||| VB.Net implements block structured error handling with
Try/Catch/Finally/End
|||||||| Try.
||||||
||||||
|||||| Ok, I see, they are frowned upon because if they are overused they
can cause
|||||| nightmares when trying to maintain code.
|||||| I guess that if you only use it here and there, there's no harm, but
I
||| can
|||||| see the problems if you start branching out all over the place with a
bunch
|||||| of them.
||||||
|||||| Can I bother you with another question then?
|||||| Very often you have a fairly long module containing a lot of user or
|||||| document interaction. Depending on the user input or the conditions
||| found in
|||||| the document, you want your code to skip certain parts of the module.
|||||| Without using GoTo, how do you get the code to jump over certain
parts
||| if
|||||| they do not apply? Is it better in such a situation to break the
module
|||||| apart in a bunch of little modules and call each smaller module as
|||||| appropriate... or are there other ways of handling this?
||||||
|||||| Thanks.
|||||
||||| HTH + Cheers - Peter
|||
||| --
||| Salut!
||| _______________________________________
||| Jean-Guy Marcil - Word MVP
||| (e-mail address removed)
||| Word MVP site: http://www.word.mvps.org
|||
|||
||
|| HTH + Cheers - Peter

--
Salut!
_______________________________________
Jean-Guy Marcil - Word MVP
(e-mail address removed)
Word MVP site: http://www.word.mvps.org