Help verify ContinueCase bug.

[John]

Not sure as I'm not working within a standard windows environment. Need someone to verify from a standard environment.

Misbehaving code snippet:

Dim $a="foo"
Dim $b="bar"

Select
    Case $a="foo"
        ;<do stuff>
        ContinueCase
    Case $b="Grrr"
        ;<do stuff>
        MsgBox(0,"$ext",$b)
EndSelect

MsgBox fires regardless case operator, "<>", "=", "==", etc. or the comparison string "bar" used.

Conditions required for the bug to occur:

The immediately previous "Case" must resolve true, thus get executed, and must contain a "ContinueCase". Additional "Cases" before and after these seem to make no difference.

Nearest bug match in bug reports:

http://www.autoitscript.com/trac/autoit/ticket/1485

[tehdon]

The example you've given and what occurs seems to behave exactly as the example given in the help file for ContinueCase.

I don't think it's a bug.

[John]

It appears your right and I misinterpreted it. I don't get the value of 'ContinueCase' with those rules, or very limited value. What I thought was that I was replacing a series of If->Then statements with a case block, where I needed all true cases to execute, not just the first true case. I guess a long series of inline If->Then statements is the only way to do it.

[MiserableLife]

well..I don't use ContinueCase at all, but instead of long series of inline If->Then statements

I think you could do this

lol('foo')

func lol($input)
    Local $a="foo"
    Local $b="bar"
    Select
        Case $input = $a
            ;<do stuff>
            Return
        Case $input = $b
            ;<do stuff>
            MsgBox(0,"$ext",$b)
    EndSelect
EndFunc

[John]

well..I don't use ContinueCase at all, but instead of long series of inline If->Then statements

I think you could do this

lol('foo')

func lol($input)
    Local $a="foo"
    Local $b="bar"
    Select
        Case $input = $a
            ;<do stuff>
            Return
        Case $input = $b
            ;<do stuff>
            MsgBox(0,"$ext",$b)
    EndSelect
EndFunc

In some languages a 'Return' keyword is needed to -prevent- Select Case from doing what I want it to. It certainly doesn't help here, as I want $a and $b to both execute if they are both true. Nor am I inside a function to 'Return' from.

Basically I'm conditionally concatenating a delimited string list to be split into an array. The $input variables and comparison $a variables are both different for each case. I have no clue beforehand which string segments will be included and which will be skipped. I certainly can't 'Return' after just one segment being concatenated.

It's easy enough to do with If->Then, but I still see no other way in AutoIt.

[JohnOne]

exactly sure I understand what you are trying to achieve.

Maybe

Dim $a="foo"
Dim $b="bar"

Select
    Case $a="foo" And $b = "Grrr"
        ;<do stuff>
        ContinueCase
    Case $b="Grrr"
        ;<do stuff>
        MsgBox(0,"$ext",$b)
EndSelect

If not, perhaps you could post an example of the If...Then code that works for your purpose.

[John]

If not, perhaps you could post an example of the If...Then code that works for your purpose.

In simplest terms I have a long list of possible -User defined- variables that are conditionally concatenated, such as:

$a1="A|B|C"

$a2="D|E|F"

$a3="G|H|I"

Etc, etc, etc...

Being completely User defined, I have no idea which groups of labels and values will be used or even exist, or what order they'll be defined.

If I use an AutoIt 'Select Case' like:

Select
  Case If $X=true       ;Is True per example
    $str=str & "|" & $a1
  Case If $Y=true       ;Is False per example
    $str=str & "|" & $a3
  Case If $Z=true       ;Is True per example
    $str=str & "|" & $a3
EndSelect

Now suppose both $X and $Z needs to be concatenated but not $Y. I have no way of knowing up front which sets should be concatenated. AutoIt Cases simply don't allow it. Placing 'ContinueCase' in $X simply falsely executes $Y when it shouldn't. Putting 'Return' at the end of each 'Case' only tells AutoIt to do what it already does anyway.

It's not a script killer and easily dealt with through If->Then, but I would like to see a way other than with a series of If->Then statements. In other words I'd like to be able to execute -every- true 'Case' statement and none of the false ones regardless of the order of the true/false evaluations. Select Case by default ends selection as soon as the first true statement is encountered with no way to change that behavior.

Long version:

I have an INI file where 'Section' is a selection label, e.g. '[internet]', The first 'Key=value' is a delimited list of application labels, e.g. 'Apps=FireFox|Internet Explorer|Maxthon', and remaining 'Value' is the paired values 'Firefox=firefox.exe' etc. Section can also be file types such as [.jpg]. The program reads the command line passed to the program, e.g. 'Internet', and displays the the program listed in 'Apps=a|b|c". Then executes the corresponding user choice.

Now this command line can be a simple string like 'Internet', or it can be a path such as 'C:\windows\Myfile.jpg', or a folder 'C:\Windows'. It selects *ALL* appropriate Drawers, not just one, and concatenates the 'Apps=' string. With Drawer' labels "[*All], [*Allfiles], [*AllFolders], and [.jpg] for any .jpg file. Drawers can even be defined for full paths, and works in both windows and Linux under wine.

It entirely replaces all file associations and also turns the program links in the Quick Launch bar into drawers with a list user defined categories of programs to launch. I've used it on windows for years, and updating for Linux to take full advantage of Linux mime types.

This is what the simplest working If->Then structure looks like:

If $cLine="Unknown" Then
    $iniSect="Settings"
Else  ; Let's concatenate all the drawer labels.
        If $dType="File" Then $iniSect=$iniSect & "*Files|"
        If $dType="Folder" Then $iniSect=$iniSect & "*Folders|"
        If $dType="Drawer" Then $iniSect=$iniSect & "*Drawer|"
        If $fileType<>"Unknown" Then $iniSect=$iniSect & $fileType & "|"
    If StringLeft($ext,1)="." Then 
        $iniSect=$iniSect&$ext & "|"
        If $dType="File" Then $iniSect=$iniSect & $fileType & $ext & "|"
    EndIf
        $iniSect="*All|" & $iniSect & $cLine        ; Concantenate first & last 
EndIf
        $iniSect=StringSplit($iniSect,"|") ; We need to make our drawer list an array to loop through.
    For $i=1 to $iniSect[0] Step 1 ;Now let's replace our drawer list with a list of app labels in these drawers for display.
        $iniApps=$iniApps&IniRead($s_iniFile,$iniSect[$i],"Apps","")
    Next

It's part of the preinitialization of variables for the GUI to display when it's created later.

[JohnOne]

I'm not sure then that continueloop Continuecase is a great idea in you case.

Personally I think your If then is the best option.

Here is an untested example of a way I would use switches to replicate the code

Switch $cLine
    Case "Unknown"
        $iniSect = "Settings"
    Case Else
        Switch $dType
            Case "File"
                $iniSect &= "*Files|"
            Case "Folder"
                $iniSect &= "*Folders|"
            Case "Drawer"
                $iniSect &= "*Drawer|"
        EndSwitch   
        Switch $fileType
            Case "Unknown"
                ;Code
            Case Else
                $iniSect &= $fileType & "|"
                Switch $dType
                    Case "File"
                        $iniSect &= $fileType & $ext & "|"
                EndSwitch
        EndSwitch
        $iniSect = "*All|" & $iniSect & $cLine
EndSwitch       
$iniSect = StringSplit($iniSect, "|")
For $i = 1 To $iniSect[0] Step 1
    $iniApps = $iniApps & IniRead($s_iniFile, $iniSect[$i], "Apps", "")
Next

Maybe you might be better using a combination of both.

Soprry I couldnt be of more help.

Edited April 4, 2010 by JohnOne

[jchd]

Having read this thread and to answer your query for "some other way", I'd like to point out that in the "case" you expose there is absolutely no advantage in using anything else than a series of distinct If..Then statements.

AutoIt Select..Case construct is clearly different from the C[++] homonym construct. AutoIt ContinueCase is specific and can't be simulated easily with anything else.

But it simply isn't the construct you need, in this example. Should AutoIt Select offer a NextCase satement which would link to the next Case test (not block), then Select would be usable for you. But since no such statement exists in today's AutoIt, the simplest is to rely on the clearer sereis of If..Endif.

Try explaining your series of test in plain english and you'll see that you won't mention Select at all. Your application requires a series of simple tests and there is no point in trying to use any other construct, particularly when none can be easily made to model your situation.

While I find it advisable to choose the best suited construct, I find it questionable that people feel reluctant to code a simple series of If..endIf because they find it "not elegant enough" wrt their coding "standard". When your condition is a series of simple Ifs, then code it this way. When it's more complex or when another construct fits best, use it.

As an aside, let me expose an anecdote. I've been working with formal method for some times. Among the bunch of tests we had for candidate engineers, we had the following.

"Try to describe best the model of a Y-type railroad shunting which directs incomming trains to branch A or branch B".

About 90% of the young engineers having an strong IT background rushed to model that "system" into an XOR operation. That always made us laugh a little. Why? Because there isn't such a thing in real-life. Railroad shuntings don't jump from A to B in zero time as XOR strictly implies. The right answer is If shunting is to A then trains go to A Endif; If shunting is to B then trains go to B Endif. With that more precise model, you can introduce notions like switching time, situations where the shunting is physically in any intermediate position and their consequences to system behavior (FMEA and friends). In short, a simple series of IFs is often more flexible and realistic than other approaches, seen as more compact or more elegant.

[John]

Thanks jchd,

The "some other way" was more a curiosity when I realized I was wrong about what ContinueCase did, but does have some developmental value to me. It's not so much that I'm adverse to If->Then constructs. But when faced with a complex selection rule and an arbitrary number of test cases to choose from it helps my conceptualization a lot when I can reformat it more than one way. I'm quiet happy with the working If->Then construct I posted, but it looks deceptively simple relative to the large number of user configurations and choices possible. It's this search for the simplest rule sets that alternative code constructs are of use to me, and doesn't actually represent an a priori preference for any one. My original If->Then block was a bit messy, buggy, and placed mild limits on what the user could do, so the Case construct was to get it straight in my head how to best improve it 'logically', irrespective of the code construct used to implement it.

This AutoIt->Linux rewrite under wine is in preparation for a command line rewrite using shell script called 'q', which will be wrapped in a python GUI. The pure Linux version is going to work as well with or without the GUI. The simplicity and extensibility beats anything windows or Linux has to offer. The usability of GUI's in Linux generally suck, and this -completely- exposes the command line to the GUI in an open ended unobtrusive user definable manner without any memory resident programs. It replaces 'Open With', command line switch choices, program drawers on the Launch bar, etc. I even use it as an option in IDEs, like SciTe, rather than the standard build menu. A must have for me.

[jchd]

I understand your approach and my post was certainly not a definitive opinion about the problem you have to solve, if ever there exists a "problem". Your quest for a cleaner presentation is laudable but there isn't always a logic construct available perfectly fitted to every problem. The dream for a universal perfect language turned out to be a dream and ADA proved it (geez, and I know what I'm talking about!). We all have some bits of code with fairly "bastard logic inside" since the problem that code solves is just awfully contrived.

I whish you best of luck with your Wine port.