If and End If

[dixie]

I have recently had to do a module with quite a number of if conditions and
several labels that are reached via a Goto label statement. My question is
a general one. If, as a result of an if... then... else... statement, the
code jumps to another label, do you terminate the original if condition in
that new label, or should it be terminated after the command that sent it to
the label?

dixie

[Bob Quintal]

"dixie" <di****@dogmail.com> wrote in
news:U3*****************@nnrp1.ozemail.com.au:

I have recently had to do a module with quite a number of if
conditions and several labels that are reached via a Goto
label statement. My question is a general one. If, as a
result of an if... then... else... statement, the code jumps
to another label, do you terminate the original if condition
in that new label, or should it be terminated after the
command that sent it to the label?

dixie
Before answering your question, I'll ask this one: if, instead of
using a goto label statement, you called a subprocedure or
function, where would you put your termination?

The answer would state quite clearly after the command that called
the subprocedure.

With jumps (goto label statements) the answer isn't clear. It
depends on where you jump to, and where you come back from. Without
having seen the code, It's impossible to tell. Besides if you jump
to a label from different places, you may need end ifs after the
label or not.

Essentially, the better (safer) way to program is to create
subprocedures from your labeled sections. Goto statements are a
nightmare to debug and to maintain.

Bob Q

[Marshall Barton]

dixie wrote:

I have recently had to do a module with quite a number of if conditions and
several labels that are reached via a Goto label statement. My question is
a general one. If, as a result of an if... then... else... statement, the
code jumps to another label, do you terminate the original if condition in
that new label, or should it be terminated after the command that sent it to
the label?

Oh boy! I hate to be negative, but you can write just about
any procedure without using GoTo. In general using GoTo is
a poor practice as it makes your procedure's logic difficult
to follow. There are several alternative constructs that
can be used to dramatically reduce or even eliminate the
need for GoTo (Select Case, ElseIf, nested If-Then-Else,
calling other procedures, etc).

To answer your question, the End If must be placed at the
end of the code that executes under control of the If
condition. Its placement has little if anything to do with
where the GoTo is located or where it jumps to.

It may seem like a daunting task, but try to recode your
procedure to remove every GoTo (except the On Error GoTo
types). If you think you've reached a point where you just
can not see a way to get rid of the last one, post back and
someone will probably be able to straighten it out for you.

--
Marsh

[Tim Marshall]

Marshall & Bob,

I remember being told by a trained programmmer back in 1991 when I was
getting back into programming after a long break from it that any GoTo
was generally poor programming practice, for precisely the reasons both
you fellows described (I was doing applications in dBaseIV at the
time). Of course, in Access VBA we use On Error GoTo Err_Proc, but here
is a instance where I often use GoTo that is not an error message and I
think breaking it out into a separate sub is a bit of a PITA.

The following could be part of any sub, say after pressing a button or
an afterUpdate event and it deals with the value entered for an input
box for a string, strValue:

Enter_Data:

strValue = InputBox ("Enter a number blah, blah")

If strValue blah blah Then 'check strValue

'If incorrect value

If msgbox("You entered an incorrect value, enter a value that blah", _
vbExclamation, vbOkCancel) = vbCancel then

GoTo Exit_Proc 'Exit point of sub

Else

Goto Enter_Data 'go back and start over

End If

End If

Hmmmm, I hate it when I answer my own question while I'm asking it. The
above can be done with a Do WHile strValue = blah Or strValue = Blah
Blah, can't it?

--
Tim - http://www.ucs.mun.ca/~tmarshal/
^o<
/#) "Burp-beep, burp-beep, burp-beep?" - Quaker Jake
/^^ "Want some?" - Ditto

[Marshall Barton]

Tim Marshall wrote:

Marshall & Bob,

I remember being told by a trained programmmer back in 1991 when I was
getting back into programming after a long break from it that any GoTo
was generally poor programming practice, for precisely the reasons both
you fellows described (I was doing applications in dBaseIV at the
time). Of course, in Access VBA we use On Error GoTo Err_Proc, but here
is a instance where I often use GoTo that is not an error message and I
think breaking it out into a separate sub is a bit of a PITA.

The following could be part of any sub, say after pressing a button or
an afterUpdate event and it deals with the value entered for an input
box for a string, strValue:

Enter_Data:

strValue = InputBox ("Enter a number blah, blah")

If strValue blah blah Then 'check strValue

'If incorrect value

If msgbox("You entered an incorrect value, enter a value that blah", _
vbExclamation, vbOkCancel) = vbCancel then

GoTo Exit_Proc 'Exit point of sub

Else

Goto Enter_Data 'go back and start over

End If

End If

Hmmmm, I hate it when I answer my own question while I'm asking it. The
above can be done with a Do WHile strValue = blah Or strValue = Blah
Blah, can't it?

In that specific case, I guess you could use a loop. But
you do raise a good point Tim. I've never come up a
satisfying approach to this kind of situation:

If blah Then
blah
Else
blah
If condition Then
GoTo CarryOn
ElseIf condition Then
blahA
Else
blahB
End If
blahC
End If
blahD
CarryOn:

Most of the time, things are not that complicated and you
can enclose the code after the If inside the Else part, but
that can place a large chunk of code an extra level deep in
the code flow and it wouldn't work in the above situation
anyway. Of course, in many other cases, there's Exit Sub,
but that violates the good practice of having only a single
exit point.

On the rare occasion, I've even used this kind of logic:
Do
If blah Then
blah
Else
blah
If condition Then
Exit Do 'Just a sneaky GoTo
ElseIf condition Then
blahA
Else
blahB
End If
blahC
End If
blahD
Loop While False
carry on

but that is just distorting the issue and at least the
earlier GoTo version is traditional enough to be clear.

I suppose its also feasible to Raise an error and pick up
the flow using Resume, but this often makes the flow even
more convoluted than a GoTo would.

All in all, I think this situation is a blot on the
GoTo-less code picture.

Maybe someone smarter than me can enlighten both of us.

--
Marsh

[Bob Quintal]

Tim & Marshall

Marshall Barton <ma*********@wowway.com> wrote in
news:ke********************************@4ax.com:

Tim Marshall wrote:

Marshall & Bob,

I remember being told by a trained programmmer back in 1991
when I was getting back into programming after a long break
from it that any GoTo was generally poor programming practice,
for precisely the reasons both you fellows described (I was
doing applications in dBaseIV at the time). Of course, in
Access VBA we use On Error GoTo Err_Proc, but here is a
instance where I often use GoTo that is not an error message
and I think breaking it out into a separate sub is a bit of a
PITA.

The following could be part of any sub, say after pressing a
button or an afterUpdate event and it deals with the value
entered for an input box for a string, strValue:

Enter_Data:

strValue = InputBox ("Enter a number blah, blah")

If strValue blah blah Then 'check strValue

'If incorrect value

If msgbox("You entered an incorrect value, enter a value
that blah", _
vbExclamation, vbOkCancel) = vbCancel then

GoTo Exit_Proc 'Exit point of sub

Else

Goto Enter_Data 'go back and start over

End If

End If

Hmmmm, I hate it when I answer my own question while I'm
asking it. The above can be done with a Do WHile strValue =
blah Or strValue = Blah Blah, can't it?

In that specific case, I guess you could use a loop. But
you do raise a good point Tim. I've never come up a
satisfying approach to this kind of situation:

If blah Then
blah
Else
blah
If condition Then
GoTo CarryOn
ElseIf condition Then
blahA
Else
blahB
End If
blahC
End If
blahD
CarryOn:

Most of the time, things are not that complicated and you
can enclose the code after the If inside the Else part, but
that can place a large chunk of code an extra level deep in
the code flow and it wouldn't work in the above situation
anyway. Of course, in many other cases, there's Exit Sub,
but that violates the good practice of having only a single
exit point.

On the rare occasion, I've even used this kind of logic:
Do
If blah Then
blah
Else
blah
If condition Then
Exit Do 'Just a sneaky GoTo
ElseIf condition Then
blahA
Else
blahB
End If
blahC
End If
blahD
Loop While False
carry on

but that is just distorting the issue and at least the
earlier GoTo version is traditional enough to be clear.

I suppose its also feasible to Raise an error and pick up
the flow using Resume, but this often makes the flow even
more convoluted than a GoTo would.

All in all, I think this situation is a blot on the
GoTo-less code picture.

Maybe someone smarter than me can enlighten both of us.

--
Marsh

Goto in dBase was impossible. it was used to move to a different
record. What I resorted to then was to create a local variable
"Cancel" and set that true if the user bailed in that condition.

I've also found that sometimes creating a few sub procedures in a
form module and calling those is an easier way of handling the
construct.

Marshall's code could look like this

If blah Then
blah
call carry on
Else
blah
If condition Then
' Do nothing.
ElseIf condition Then
blah
call blahC
call blahD
call carry on
Else
blahB
Call blahC
call blahD
call carry on
End If
End If
End sub
sub blahB

Advantages: Code re-use, easier editing ( I hate where you can't
see the If from it's End If or because of the quantity of nested
statements, the left side of the page.)

But I will sheepishly admit that I do use labels sometimes.

Bob Q