Do Until Loop 3

[Guest_imported]

Is there a way to skip an iteration of a loop in the middle.
I have a test condition in the middle of a loop, if true I want to continue with the next iteration of the loop
Thanks

 

[woyler]

You can set a flag as the loop criteria.

Do until bFlag

if Criteria Met Then
bFlag = True
'break loop
else
bFlag = False
'continue processing
loop

 

[Crundy]

Probably better to do this:

Do
if condition = True then exit do
loop

in case you're testing another condition with the loop.

e.g:

s=1
Do
response = MsgBox("another box?", vbYesNo)
If response = vbNo Then Exit Do
s=s+1
Loop until s=10

Then you'll only get it ten times, or until the user clicks 'no'

 

[woyler]

You really should try to avoid Exit statments.

 

[shepherd]

Listen to woyler... Though I'd make one change to his code:

Do until bFlag
'Do your processing here
If Criteria Met Then
bFlag = True
End If
loop

The Else statement isn't really necessary. Just make sure that your criteria will be met.

 

[rvBasic]

I think Woyler's solution is better than shepherd's because if the Criteria are met the very first time you enter the Do Loop, the processing will not be executed.

In shepherd's solution, the processing will be done at least once, even if the criteria are met.

Depending on what you really want, the Else statement may justify its use ... _________________________________
In theory, there is no difference between theory and practice. In practice, there is. [attributed to Yogi Berra]

 

[shepherd]

Actually that's not true. Because the loop contains the processing code, on the very first iteration of the loop, you don't need to check if the criteria is met because no processing has been done yet. Do your processing, then check if the criteria (result of that process) is met.

As far as the Else statement, the only reason why I said it wasn't necessary in this particular case was because his flag will retain its initialized value until it's explicitly changed - there's no need to keep assigning it a value of False every loop - it's not really bad or anything, its just not as efficient. These are really minor points, but they add up quickly depending on how many times you go through that loop...

 

[ScottGS]

If I am reading the question right, I think VBProgrammerJ doesn't want to stop the loop in the middle, just skip that iteration.

Use this structure:

do while <loop condition>
if not <skip condition> then
' Processing here.
end if
loop

This will loop until <loop condition> is false, and will skip just that iteration if <skip condition> is true.

Scott

 

[strongm]

Woyler and Shepherd make tough calls with their their comments.

>You really should try to avoid Exit statments

Well, this is a question of programming style. There's at least one school of though that suggests that any procedure and/or function should have only one entry and one exit point. Subscribe to this (and the main reason for following it is code readability) and the comment is fair. It is not, however, a rule that should be followed blindly.

Sheperd's comment on where you check the condition involves a more obscure point. It relies on the fact that the default value of an uninitialised boolean. if you are happy with assuming the way VB will work with defaukts, and have no requiremnt for explicetness in your declarations for commenting purposes, then he is probably right. On the other hand, if you want to be explicit - and want the code itself to document what is going on - then Woyler's explicit assignation of the value of bFlag ,whether the condition proves to be true or false, is the better approach.

 

[MichaelRed]

Ouch. There must be a bad case of ???????? here. Only ScottGS seems to have read the question.

MichaelRed
mred@att.net

There is never time to do it right but there is always time to do it over

 

[shepherd]

Well, if you notice, I didn't submit an entire procedure, just a piece. And, I was assuming that the boolean would have been initialized before the snippit I submitted (i.e. when variable declarations were made) - the idea remains the same. I also agree with woyler regarding the exit statements. You really should never have more than one entry and exit point for a function. The main reason is not readability, it's keeping bugs out of your code. That said, readability is a great thing...

 

[strongm]

But, if that's the case, Woyler's comment comes in to play - the fact that you can avoid processing the code at least once...

Notwithstanding the fact that MichaelRed is correct concerning the thrust of the original question, I think it is worth exploring some assumptions stated in this thread.

Whilst a pure computer science-based argument would agree that one entry point and one exit point from a routine is a good thing, I would still argue that in VB the only reason for sticking to that approach if for readability. The convolutions that you sometimes have to go through to achieve that (error handling being a good example) are as likely - if not more so - to introduce flow of control errors than the acceptance of the idea of having extra exit points. Hence my point that it is a reasonable guideline, but not a rule that should be blindly followed.

Counter-arguments on a postcard, please...

 

[MichaelRed]

Again, I really dont think the respondents are reading the posts. I have either missed the line which is discussed or the Exit is only exiting a loop. This IS NOT the same as multiple exits from a procedure. It (Exiting loops) is shown and endorsed in many programming examples and languages from every 'language' vendor whose I have ever used. Having learned at least a few languages, over a few years, I have adopted the approach of adopting programmming 'styles' which appear (to me) to offer the clearest expression of the problem. In the most general sense, the single entry single exit sytle works. In MANY specific circumstances, it is just so much overhead. My Classic example of when the single exit is 'overhead' occured in the largest parse/find/replace program I ever personally wrote. I generally refered to the thing as not just finding the needle in the haystack, but finding the one (out of several hundred) with the correct serial number. I ended up with nothing except a huge number of nested select case statements, most with some type of loop in the innermost level. I chose to just Exit the procedure whe the correct needle was found and processed. Of course, I COULD have done the &quot;Style&quot; thinggy. Set a flag (or two), Exit the loop, Check the flag, find that I was done, do the 'goto xxx&quot; and exit from that point. But that was four of five steps, tracing through several pages of code to achieve a &quot;one liner&quot;. NO Contest.

Long away and far ago, back in the days of Guru's like &quot;Yourdon&quot;, the world of software adopted the battle cry of &quot;Structure&quot;. Structured Design. Structured Programming. Structured Walk Throughs. Structured Structures. Like every 'new' approach to software, it has some (actually in this case many) good concepts to make dealing with code much easier. It also included some 'nice' ideas whose use were more academic than totally necessary or even pratical. One-In / One-Out is, for me, in the latter category.

I worked at (the now defunct) Singer Corporation, where the PTB often hired the Guru's (a.k.a Yourdon) to help / teach these concepts, one which I rember VERY vividly was the concept that if the routine didn't fit on one page, it was to big and needed to be broken down into smaller units. Well this has come and gone. It is still recommended that routines which are 'Large&quot; be broken down - but I do not ever here a requirements of &quot;one page&quot; or &quot;50 lines&quot; applied to a procedure. I place the one-in / one-out restriction in the same category.

MichaelRed
mred@att.net

There is never time to do it right but there is always time to do it over

 

[strongm]

<applause>

 

[ScottGS]

VBProgrammerJ,

Did any of us actually answer your question? Many good points have been made regarding structure, but I'm not sure that any (including my first post) actually answered the question you asked?

Scott

 

[shaddow]

Here is an example

Do until condition
'Do your processing here
If Criteria Met Then
goto label1
End If
'Do your processing here
loop
label1:
'Do your processing here
________

George

 

[strongm]

Er, shaddow, that might not be a particularly good example...

 

[Aws]

Too bad, Delphi Pascal has &quot;continue&quot;:

The Continue procedure causes the flow of control to proceed to the next iteration of the enclosing for, while, or repeat statement.

(Just learning VB myself; would love to see a list of differences - )

 

[shaddow]

U could tell me why? ________

George

 

[strongm]

Sure. You are jumping out of an If statement, which is bad practice.