0 > 1. So is empty

[jacque]

While the code in the OP works as the Dictionary describes, I'm not sure the implementation is best. After all, the block in question about item 4 leads with a case that evaluates to false, so while I would expect all others to fall through I would not intuitively expect that case to fire.

Agreed, it does seem odd. I think it's like Bernd said, the structure acts like a logical OR operation.

[dunbarx]

Jacque.

Right. This is standard form, though here "ganged" cases all point to a single command, and break out explicitly. The "conditionals" are inherent in the parameter following each case instance.

I thought you had done what I presented, where each case may or may not fire:

Code: Select all

switch
   case pChoice contains "carrot" or pChoice contains "beans" or pChoice contains "lettuce"
       put "vegetable" & return after tObject
   case pChoice contains "tame" or pChoice contains "houseBroken" or pChoice contains "personal"
      put "pet" & return after tObject
   case pChoice contains "dog" or pChoice contains "cat" or pChoice contains "mouse"
      put "mammal" & return after tObject
   case pChoice contains "parrot" or pChoice contains "sparrow" or pChoice contains "hummingbird"
       put "bird" & return after tObject
  end switch

So if you invoked this with (pseudo):

Code: Select all

put "houseBroken parrot" into pChoice
run the switch

you would get "pet bird", and nothing else.

Craig

[jacque]

If you swap cases 2 and 3, you do get "pet bird". It appears to run through all cases after the first match. If there are no matches you get nothing.

I have used conditional cases in the past but I can't remember where, and I don't remember whether there were fallthroughs or not. I know I've never hit the issue we're discussing though. Maybe the LC team will agree with your report.

[dunbarx]

Jacque.

The trick is not to have to order the case statements so that they perform the way you need them to. The trick is to have the condititionals determine the way things perform.

Craig

[AxWald]

Hi,

ever avoided "switch/ case" for this. I just don't get the way it works.

I'd expect:
- if there is a "break" in the first "true statement", it exits at it.
- if there is no "break" in a "true statement", it & all following "true statements" are executed.
(Until one has a break)

So basically:
- "break" in a "true statement" exits after execution
- no "break" means other following "true statements" are executed, until one has "break" or the loop ends.
- "false statements" are never executed.

I may be completely wrong, for sure :)
As mentioned, it confuses me - so I keep my hands off ;-)

Have fun!

[dunbarx]

AxWeld.

My point from the start was that, without explicit "break" lines, after a "true" evaluation, subsequent case statement conditionals which evaluate to "false" are executed as well. That seems unseemly to me.

What I assumed, and filed an enhancement request for, was that a series of case statements without breaks would fire based solely on their evaluations. In other words, you are not forced to exit the construction at the first "true" evaluation; you may continue and perhaps find others.

This may actually have gotten the attention of the team, as they have confirmed the situation, and indicated they are working on it.

We will see...

Craig