AutoIt equivalent of C++ break?

[KCE]

What is the autoit equivalent of C++ break for switch statements? According to AutoIt help, ExitLoop will only break out of a While, Do or For loop. And ContinueLoop doesn't seem to be what I need. I'm thinking I should just use a chain of Else-If's.

Edited February 8, 2010 by KCE

[whim]

AFAIK the logic in AutoIt is the reverse of C: you don't need break if you want to leave the Switch after a Case is triggered;

if, on the contrary you want the C default, i.e execution continues into the next case, use ContinueCase

(from the help file for ContinueCase)

Normally in a Select or Switch block, a case ends when the next Case statement is encountered.

Executing the ContinueCase will tell AutoIt to stop executing the current case and start executing the next case.

HTH,

whim

Edited February 8, 2010 by whim

[PsaltyDS]

What is the autoit equivalent of C++ break for switch statements? According to AutoIt help, ExitLoop will only break out of a While, Do or For loop. And ContinueLoop doesn't seem to be what I need. I'm thinking I should just use a chain of Else-If's.

And how do you think you would "break" out of a chain of ElseIf's?

Switch, Select, and If/ElseIf are all conditional logic, not loops. So this whole "break" conversation is a little confusing in that context. Post an example script so we can see what you mean.

Edit: Ahh, so! As weaponx pointed out, AutoIt is not C++ and the "break;" is implied at the end of every Case.

Edited February 8, 2010 by PsaltyDS

[weaponx]

AutoIt doesn't need a break statement for conditional functions, each condition is automatically broken. In C++ and php, switch and select will cascade if break is not used, in AutoIt the only way to cascade is by using ContinueCase.

[KCE]

What I have in mind is "break" will exit the case on the spot instead of having to wait to reach the end of the case block to actually exit.

For example, instead of this:

Switch

    Case 1
        If blah = 0
            code
        EndIf
    
    Case 2
        ...
        
EndSwitch

...

I'd rather do this but "break" doesn't exist. If I use ContinueCase it would go to Case 2 which I don't want. What I want "break" to do is to exit the switch statement entirely and execute the last ...

Switch

    Case 1
        If blah = 1 Then
            break
        EndIf
        
        code
    
    Case 2
        ...
        
EndSwitch

...

Another way I could do this is to set a global variable and then have each of the cases do ContinueCase if the global variable is set, but this seems unnecessarily complicated to me.

Global x = 0

Switch

    Case 1
        If blah = 1 OR x = 1 Then
            x = 1
            ContinueCase
        EndIf
        
        code
    
    Case 2
        If blah = 1 OR x = 1 Then
            x = 1
            ContinueCase
        EndIf
        
        ...

    Case 3
        If blah = 1 OR x = 1 Then
            x = 1
            ContinueCase
        EndIf
        
        ...     
        
EndSwitch

...

Man I miss curly brackets lol. Rather then a nest of if checks I'd rather do a series of if checks. Basically I try not to use too many nests unless I have to.

Edited February 11, 2010 by KCE

[Xand3r]

Select
    Case $var = 1 And $blah <> 1
        code
    Case $var = 2 And $blah <> 1
        code

[LondonNDIB]

I'm with the OP on this old topic.  Of course a break isn't NECESSARY, but then... neither is the Switch at all ( you can do it with a series of IF statements ).  The point is easier to read (and write) code.  Being able to break out of a case would be useful.  In fact, I've thought of it so many times that I finally decided to search and see if there was a way I wasn't seeing.

I can (and do) write my code to skirt around this unfortunately missing piece of flow control, but it would be nice if I didn't have to.

Please implement a break!

Edited January 2, 2015 by LondonNDIB

[MikahS]

This was from almost 5 years ago. The last time the author was active, was Feb 15 2010 10:11 PM.

Send("{BREAK}")

[Jos]

 

This was from almost 5 years ago. The last time the author was active, was Feb 15 2010 10:11 PM.

Send("{BREAK}")

.. and your point is ?

LondonNDIB is merely stating a case and uses an old topic to add on to. In case you feel a topic needs moderation then refrain from posting and simply report it.

Thanks.

Jos

[MikahS]

No problem, wasn't meant to get everyone into tiff.

Just thought if LondonNDIB wanted to have a discussion about this the post should go into the developer chat, where everyone could take part, not in a 5 year old thread (you can see where this logic failed me ha).

My apologies.

Edited January 2, 2015 by MikahS

[LondonNDIB]

I know some are of the "don't bring up old #$@@!" mind.  I am, personally, in the "don't start a new thread when one already exists" camp.

If your Send("{BREAK}") was meant seriously... that doesn't really work, does it?

Edited January 2, 2015 by LondonNDIB

[MikahS]

It's essentially like sending a CTRL + Break, I don't know if that was exactly what you wanted, but thought you might want to give it a try. It won't hold execution, but the break statement is used with the conditional switch statement and with the do, for, and while loop statements.

Essentially the break statement for this language is ExitLoop.

EDIT:

I know some are of the "don't bring up old #$@@!" mind.  I am, personally, in the "don't start a new thread when one already exists" camp.

 

No problem, apologies if you felt attacked. That was not what my intentions were.

Edited January 2, 2015 by MikahS

[Melba23]

LondonNDIB,

 

I know some are of the "don't bring up old #$@@!" mind. I am, personally, in the "don't start a new thread when one already exists" camp

We generally prefer that you start a new thread and link to the old one if really necessary. We say this for two main reasons:

 

- 1. The language advances and the functionality asked for in old threads might well be included in core or UDF code by now.

- 2. The changes in language syntax mean that it is likely that code from more than a couple of years ago may well not run under the current release interpreter without significant modification.

I realise that is not the case here, but we would still be grateful if you could try to fit in with our way of doing things.

M23

[LondonNDIB]

Now I know!

@Mikah... Switches aren't loops, so exitloop isn't appropriate.  Sending the {break} didn't work (didn't think it would but thought I'd try it just in case).

 

I still think an ExitCase (or even ExitSwitch) device would be very handy.  Not necessary, no... but cleaner.  I've run into a few cases where reversing logic doesn't really work so I'm left with an ugly series of IF statements and $flag variables.

Ah well.

[MikahS]

@Mikah... Switches aren't loops, so exitloop isn't appropriate.  Sending the {break} didn't work (didn't think it would but thought I'd try it just in case).

 

No problem, I took that line right from the microsoft C++ documentation on break statements.

Edited January 2, 2015 by MikahS

[aleph01]

Somewhat off-topic, but I would like to know if nesting if checks is faster than a series of if checks, especially if the series of if checks are one-liners, without the EndIf. Or is the speed difference insignificant?

_aleph_

[SmOke_N]

There's no break; but if you setup your select/switch strategically, ContinueCase acts very similar.

@eleph01; there have been several tests on speed differences in the example forum.  To be honest, I barely remember the outcome, which would mean to me, it's negligible.