Nested If statements

[GLT]

Hi,

I have some nested if statements which are as follows:

read one line

if condition <a> is true

read another line

if condition <b> is true

read another line

if condition <c> is true

read another line

endif

endif

endif


What I would like to happen if condition <a> is true, then it jumps to the
next if statement, and keeps doing so - only exiting ALL of the if statments
if a condition winds up being false.

The current method above will exit all the if statments if the first one is
true. I have 25 if statements, and I only want my code to proceed with the
next if statement if the previous if condition is true.

Can anyone advise the correct way to acheive this?

Any help is always greatly appreciated...

Thanks,
GLT.

 

[Stefan Hoffmann]

hi,

What I would like to happen if condition <a> is true, then it jumps to the
next if statement, and keeps doing so - only exiting ALL of the if statments
if a condition winds up being false.

If I understand you, you have only the remove the <readLine> statements:

If <conditionA> Then
If <conditionB> Then
End If
End If

These nested If's are exiting all statments when one condition is not
met, as they are nested.

The current method above will exit all the if statments if the first one is
true. I have 25 if statements, and I only want my code to proceed with the
next if statement if the previous if condition is true.

Huh?

What are you doing exactly? Maybe there is another solution (Select
Case, a proper Function or Sub) ?


mfG
--> stefan <--

 

[GLT]

Hi Stefan

Thanks for your reply, I want to be able to perform multiple if conditions
(one after the other), but if one fails, then it stops testing ALL of the if
statments and starts all over again...

If i nest if statements, it will exit the first one thats true. In effect I
want to do this:

If condition <a> is true

perform action

end if

if condition <b> is true

perform action

next if

if condition <c> is true

perform action

end if

However, if one of the if conditions are false, the I want the next 25 if
statements to be false and the loop starts again from the beggining...

Hope I was more clearer this time ...

Cheers,
GLT

 

[james.igoe]

THis is a little bit off what you need, but you can use a Select Case,
such that the arguments are separate functions that return a boolean
(true/false). If any of the functions fails, the process ends,
otherwise, it proceeds to the Case Else, which is typically just a
message that the process succeeded, as follows:

Select Case False

Case (arg1)

Case (arg2)

Case (arg3)

Case Else

End Select


James Igoe

http://vba.wikidot.com/
http://code.comparative-advantage.com/

 

[BruceM]

The meaning of "I want the next 25 if statements to be false" is unclear. A
description of the real-world situation could be of help.
That being said, maybe you could test for the opposite of what you want:
If Not ConditionA = True Then ...

In other words, you may be able to contrive so that a False statement
evaluates as True. However, if the 24th "If" is True using this method,
there is only one more If statement, which is why I wondered about your
specifying the "next 25 if statements".

A Select Case may be a better choice than attempting to nest 25 If
statements, or there may be another choice that involves looping through
fields with code. Again, a non-database description of the situation may
help somebody identify a solution.

 

[Ron2006]

I have never seen a problem with nested ifs but that is not to say
that there isn't one with that many.

reverse your logic.

readone line

if condition <a> is false then
goto endofallreads
endif

read one line

if condition <b> is false then
goto endofallreads
endif

read one line

if condition <c> is false then
goto endofallreads
endif

etc.


place here the code if ALL reads are good.

endofallreads: 'tag name to go to if ANY read is bad.



Ron

 

[Stefan Hoffmann]

hi Ron,

I have never seen a problem with nested ifs but that is not to say
that there isn't one with that many.

Your exampel is the logic equivalent to that of the OP using negation.


mfG
--> stefan <--

 

[BruceM]

I did not say there was a problem with nesting twenty-five Ifs (although I
don't know for sure), although twenty-five closing parentheses would be
unwieldy at best, and difficult to maintain if the number changes. That was
why I suggested Select Case may be easier to use.
In both If statements and Select Case, if I understand the documentation
correctly the rest of the expression is essentially skipped as soon as a
statement evaluates to True. The OP wants to test each condition, and stop
only if the condition is False. This is the opposite of how If and Select
Case work, so I suggested a possible way to have a True statement to
evaluate to False and vice versa. Not True = False, and Not False = True.
I tend to avoid GoTo except for error handling. That being said, your
example exits the If no matter whether the statement is True or False, so it
will never get past the first test.
I asked the OP to describe the real-world situation, partly because the
question is puzzling. For instance:
"if one of the if conditions are false, the I want the next 25 if statements
to be false and the loop starts again from the beggining". The next 25?
What if the 24th condition is false? There is only one more. If it is
false, are all 25 conditions to be False? If so, are the conditions fields,
variables, or what?

 

[Klatuu]

A construct much like you posted will do what you are wanting

If A Then
'Do A Stuff
If B Then
'Do B Stuff
If C Then
'Do C Stuff
End If
End If
End If

Now, 25 layers deep it would be a bit hard to read and I don' know if there
is a nesting limit for the If Then Else statment. So, there are a couple of
other options. The preferred option would be to put the conditionals in a
sub or function by themselfs and use the Exit Sub/Fuction when a condition is
false. The Exit statement is a venial sin in structured programming, but it
can be forgiven when it makes your code more straight forward and easy to
read. Or you can commit the mortal sin of using the GoTo. Use this method
only if for some reason (like varialbe scoping) you can't move the code to a
different procedure. The way you would implement this would be to bypass the
remaing code on the first false statment:

If A Then
'Do A Stuff
Else
Exit Sub
End If

If B Then
'Do B Stuff
Else
Exit Sub
End If

Or

If A Then
'Do A Stuff
Else
GoTo ConditionsComplete
End If

If B Then
'Do B Stuff
Else
GoTo ConditionsComplete
End If

ConditionsComplete:

Neither is good, but sometimes you do what you have to do.

Just thought of a third way. Use a boolean varialbe to determine whether to
even test the rest of the series:

Dim blnCarryOn As Boolean

CarryOn = True
If A Then
'Do A Stuff
Else
CarryOn = False
End If

If CarryOn Then
If B Then
'Do B Stuff
Else
CarryOn = False
End If
End If

 

[BruceM]

What is the alternative to Exit Sub, and why is it a venial sin? I tend to
use it when Cancel = True is not available. For instance, a Double Click
event has the option to Cancel, but a Click event does not. I can't imagine
why this is so, but in any case there are times when I wish a Click event
could be cancelled. For instance, the user may be asked to choose an
option. If they click No, don't perform the Click event. There are
probably ways around this, but they can be clumsy. I guess this is where
the forgiveness of which you speak comes into play.
By the way, I expect Exit Sub in error handling is in a different category
than when it is used in the rest of the code.

 

[Klatuu]

I use the Exit Sub as well. All I am saying is that in pure Yordan
structured programming, you should never prematurely exit a procedure.

It is like database normalization. One strives for a perfectly normalized
database and only denormalizes when performance or business rules dictate.
Even when you want to follow Yordan rules as closely as possible, there are
times when readability of the code becomes more important than the rule.

So, it is one of those things you would rather not do if there is a
reasonable way to avoid it.

 

[BruceM]

OK, the key word is "reasonable". Thanks for the reply. I don't use Exit
Sub often, but as you said, readability counts for something too.

 

[Klatuu]

Yes, reasonable is always a key word.
BTW, I misspelled Yourdan's name. Hope he isn't watching <g>

 

[BruceM]

That explains to some extent why a Google search wasn't getting me anywhere.
I say "to some extent" because (at the risk of seeming picky) my searches
have led me to conclude the name is Yourdon.

 

[Klatuu]

To be even pickier, it is Ed Yourdon. <g>
Was the guru of structured programming techinques back to the late 1970's
Many shops adopted his rules as standards. In reality, Event driven
programming didn't even really exist at that time, so his principles were
even more important than now to avoid "spagetti" code. More modern event
driven languages (VBA included), by their nature, eliminate many of the
problems inherent in procedural languages. But, having been "classically"
trained <g>, I still adhere to most of those principals.

You can certainly see where the injudicious use of an Exit Sub could break
code and the unbridled use of GoTo could make code really hard to follow and
maintain. I don't know if you ever coded in some of the earlier versions of
basic with line numbers and no gosubs, but with only the GoTo to use for
branching, I have had to maintain code that would make an NFL linebacker cry.

 

[BruceM]

Many years ago I did some programming in Basic +, but I don't remember much
about it, except I seem to recall the use of GoTo. This was in the days of
punch cards, and my path soon led me away from computers for some years, so
I didn't get into it in much depth. However, in more recent times I have
seen VBA code with strings of GoTo statements, so I have some sense of how
gnarly that can be.