Are all the false cases empty? If so, you could build the Booleans into a number and then feed that number into a case structure with only one case for each, errr, case.
They are not empty, they include the code necessary to evaluate the condition. In some cases it can be time consuming (like acessing a database) to evaluate in advance all the conditions to decide which case to execute. That is why conditions are evaluated only when the result is needed like in the embedded case structures.
Instead of using embedded case structures, I chained them one after the other but I need a three value wire:False, True and Done. The Done case is used to skip all other cases after a case True has been executed. That is the closest thing to an elseif structure.
Especially when handling errors, this could make code a LOT more readable.....
It helps to keep the code readable. While it IS possible to mimic the behaviour otherwise (as crelf points out) I think this could be a VERY useful tool in certain circumstances.
Like this example wherewe might have errorsin any one of three places (in series)....
This would require the Selector for a Case to no longer be in the middle of the active frame (See pictures above).
Compared to the current option:
At least for me it looks cleaner. There's less going on in the diagram for the same information. A better signal-to-noise Ratio I would say.....
This was proposed inside R&D a few years ago... One adjustment to the picture as you've drawn it here: you need to have the True case go all the way across the structure so that your output tunnels are all in one location. That was a restriction that some people didn't like -- all the output tunnels had to be on the right edge, not the top or the bottom or the left, because if they were top/bottom/left, not all frames would have access to them. And there was some distaste for having to wire input tunnels from the left across to reach all the nested frames. Finally, there was a complaint about all the frame flipping that had to be done with the left-to-right model, which led to the proposal of putting nodes *in the drop ring* itself, so that it could be a traditional Case structure, but you could have evaluated expressions in the cases, and we would execute the first one that evaluated to True. That got messy to prototype and never went very far.
There's probably room for improvement with the Case structure's expressiveness, but the idea as currently proposed has some major problems that I don't think can be easily addressed.
As a note to JeanPierre: May I suggest adapting the State Machine paradigm for your else-if construction --- you start in State 1, evaluate some expression, if it comes up true, you do some local stuff and transition to Done state, and if it is false, you transition to State 2. Much simpler to code, both in terms of mouse clicks and adaptabilty if you need to insert interim tests or reorder tests.
AQ, it's nice to know that something in this direction has been considered before.
I feel that a State Machine gives a very different impression when looking at the block diagram than a cascaded Case structure like this. I need to actually analyse a state machine to know what it does whereas a cascaded for loop is pretty much self-explanatory.
Shame the idea never got far. 😞
Edit: Wouldn't linked tunnels save some of the hassle of wiring, just like in a FOR loop or a WHILE loop....? Personally, I always have input on the left and output on the right anyway so this wouldn't bother me in the least.
Stephen, back then it may not have existed, but these days we do have the ability to have an inner structure get an input from the outside of the outer structure without using a wire - the feedback node's initializer, which works quite well. If Altenbach's proposal of adding an output terminal for the feedback node is implemented, I believe that should solve the output issue as well. There was also a suggestion for splitting a wire in two which would also help with this.
I agree that the sort of structure suggested here would be beneficial and that it has obvious advantages over a state machine in readability.
What if it was a little more like a switch statement in C? You could wire a cluster of information to the input. Each page of the case statement would have a statement that defined what it handled, such as "A<3 and B>4". If this was false, it would drop through to the next case. If none of the cases were true, it would drop down to the default case which would always be last.
It might be a little confusing to keep track of the order of the cases. We might need some sort of tool for viewing the whole list of cases and editing each case.
This would have saved me a bunch of time in a recent program, where there were three possible values for A and three for B, as well as C and D. The cases ended up being nested four deep, which is something of an editing nightmare. The ability to do multiple comparisons within a single case statement would have been wonderful.
Now that I have written this, I think I will post it as a new idea. I think it is sufficiently different from the original post to warrant this.
