[RESOLVED] Is there any Break state ment in V.B like c ?

[raghunadhs]

Hi All,
in C-language, we have a "break" state ment. like that is threre any key word in V.b 6.0?

my requirement is:

if intArray(i)=intElement then
i have to break the if
end if

How can i do this?
Thanks:
regards:
raghunadhs.v

[RhinoBull]

As I recall Break would terminate current loop. In VB there are several ways to exit loop depending on its type:

Exit Do
Exit For

However, if you are using the While-Wend loop then there is no way out.
The fix for that is to susbstitute that with Do-While or Do-Until.

[Mark Gambo]

Also:

Exit Sub

[RhinoBull]

No Mark, Exit Sub/Exit Function both have different purpose but under sircumstances may work too I guess.

[Ellis Dee]

The break statement in C doesn't break out of loops. (EDIT: This is wrong; it does break out of loops, but it also breaks out of switch blocks.) It breaks out of a Switch statement, which is the equivalent of Select Case. For example:

Test = 1;
Result = 0;
Switch Test
{
    Case 0: Result = 10;
    Case 1: Result = 200;
    Case 2: Result = 3000;
}

The above code would assign 3000 to Result because there is no break statement. The proper way to code it would be:

Test = 1;
Result = 0;
Switch Test
{
    Case 0: 
        Result = 10;
        break;
    Case 1: 
        Result = 200;
        break;
    Case 2: 
        Result = 3000;
        break;
}

This would give the expected 200 value for Result. It may seem silly to require the use of the break command, but it allows for some nifty logic.

Visual Basic has no ability to mimic a break statement because there is no way to fire two different Cases in a single Select Case statement.

[RhinoBull]

The break statement in C doesn't break out of loops...

Of course it does.

[Ellis Dee]

On second thought you could mimic the behavior with GoTo statements like this:

Select Case Test
    Case 0
        ' Do stuff
        GoTo Case1
    Case 1
Case1:
        ' Do stuff
        GoTo CaseBreak
    Case 2
Case2:
        ' Do stuff
        GoTo CaseBreak
End Select
CaseBreak:

I wouldn't recommend it, though.

[peteleeb]

Ellis, that poses an interesting question. At least for me. In your, or anyone's experience, has this need every been justified? I have been coding (amaturely, though) for some time (since the TI-99 and Commadore-64) but when I switched to event driven languages every thing I read from the pros warns against using the Goto except in extreme cases. Would using Gotos help to increase performance? though thinking about it I would doubt it.

[Ellis Dee]

Ellis, that poses an interesting question. At least for me. In your, or anyone's experience, has this need every been justified? I have been coding (amaturely, though) for some time (since the TI-99 and Commadore-64) but when I switched to event driven languages every thing I read from the pros warns against using the Goto except in extreme cases. Would using Gotos help to increase performance? though thinking about it I would doubt it.

There are certain circumstances where the use of GoTo is completely justified. I once read a paper about it, but can't seem to dig it up using googol. I'm pretty sure it was Hopkins' rebuttal to the Dijkstra (or was it Wulf?) paper titled "GOTO considered harmful."

[Code Doc]

There are certain circumstances where the use of GoTo is completely justified. I once read a paper about it, but can't seem to dig it up using googol. I'm pretty sure it was Hopkins' rebuttal to the Dijkstra (or was it Wulf?) paper titled "GOTO considered harmful."

-----------------
Yes, I agree. GoTo statements give me the creeps, but on occasion you have to use them. One example comes to mind. Suppose you are checking for a unique file that you know must be on the root of a CD ROM drive but you really do not know what that drive letter is. You check the available drives and use error trapping if the CD is not inserted. When all available drives are exhausted, you prompt with a message to insert the proper CD in the drive or Cancel.

The easiest way to resume the check is with a GoTo and start the search over again above the loop. I've tried writing this routine inside Do...Loop, While...Wend, and For...Next with little success and strange results often occur. My conclusion is that the unconditional branch is not quite dead.

[Ellis Dee]

-----------------
Yes, I agree. GoTo statements give me the creeps, but on occasion you have to use them. One example comes to mind. Suppose you are checking for a unique file that you know must be on the root of a CD ROM drive but you really do not know what that drive letter is. You check the available drives and use error trapping if the CD is not inserted. When all available drives are exhausted, you prompt with a message to insert the proper CD in the drive or Cancel.

The easiest way to resume the check is with a GoTo and start the search over again above the loop. I've tried writing this routine inside Do...Loop, While...Wend, and For...Next with little success and strange results often occur. My conclusion is that the unconditional branch is not quite dead.

I wouldn't use a GoTo for this. Instead I would check errors manually instead of using a GoTo for the error trap. Something like:

blnFound = False
Do
    For i = LBound(strDrives) To UBound(strDrives)
        On Error Resume Next
        blnFound = (Dir(strDrives(i) & strFile) <> "")
        On Error Goto 0
        If blnFound Then Exit Do
    Next
    If MsgBox("Insert CD into any drive and press Ok", vbOkCancel) = vbCancel Then Exit Do
Loop
If Not blnFound Then Exit Sub

[Code Doc]

Ellis, I'm a little concerned about that On Error Goto 0 statement. My understanding is that this "disables error handling in the current procedure."

What affect is that going to have on subsequent processing beyond the Do...Loop in the same procedure that requires further error trapping?

[Ellis Dee]

Ellis, I'm a little concerned about that On Error Goto 0 statement. My understanding is that this "disables error handling in the current procedure."

What affect is that going to have on subsequent processing beyond the Do...Loop in the same procedure that requires further error trapping?

Sub Sample()
On Error Goto SampleErr

    ' Do stuff
    blnFound = False
    Do
        For i = LBound(strDrives) To UBound(strDrives)
            On Error Resume Next
            blnFound = (Dir(strDrives(i) & strFile) <> "")
            On Error Goto SampleErr
            If blnFound Then Exit Do
        Next
        If MsgBox("Insert CD into any drive and press Ok", vbOkCancel) = vbCancel Then Exit Do
    Loop
    If Not blnFound Then Exit Sub
    ' Do more stuff

SampleExit:
    Exit Sub

SampleErr:
    MsgBox Err.Description, vbInformation, "Error #" & Err.Number
    Resume SampleExit
End Sub

[RhinoBull]

Nothing personal but I would fire someone for such coding.

[Code Doc]

OK, Ellis, I think I see where you are coming from on this. I'll play around with it. I like the simplicity for your code. Mine is a bit more complex but works.

I once had a user who called saying that the program was refusing to accept the CD in the drive. It would whirr and whirr and my APP message box kept popping up to insert the proper disk. She was sure the drive and the disk were flawless. I thought for awhile and then said, "Reject the disk and let it sit there for a second."

She did. Then I asked, "Can you read the label on the CD?"

She said, "Not without turning the CD over. It's on the other side."

'Nuff said. Apparently the drive was not ejecting the disk automatically when flipped.

[Ellis Dee]

Nothing personal but I would fire someone for such coding.

Is that directed toward me?

[RhinoBull]

Of course not - like I said "nothing personal". However, if that is how you normally do things then you may need to reconsider your coding technics.

[raghunadhs]

Thanks to All....
Thank you very much.
regards:
raghunadhs.v

[Al42]

Ellis, I have to disagree with you. The only time GoTo is justified in VB is On Error GoTo xxx. Any other situation can be coded with the proper conditional code and no GoTo statement.