As you can see, nested Switch/Case groups are supported.
You can now drag-and-drop elements up and down within the prompt and click OK to submit it. The selected action in your macro will be replaced with your newly rearranged version. If you change your mind, just use KM's Undo feature (āZ).
Can I change the font size for ācase-valueā in the āCustom Promptā without causing any unwanted side effects? Iād like to display more entries. The same question applies to āmax-heightā in ācase-list-wrapā. (Long lists look better on my 24-inch screen at 1200 px.)
If/Else only has two possible states, and while I can imagine reorganising a complex series of nested If/Else actions, I don't think it would be any quicker in a prompt than in the KM Editor's own interface.
I specifically targeted Prompt for User Input and Switch/Case, as you can end up with dozens of entries that are laborious to rearrange manually. If there are other examples you can think of that pose the same challenge, I can try to add them.
The cases Iāve dealt with truly are time sponges, whereas rearranging conditions seems somewhat luxurious, so Iām less inclined to further complicate things by parsing a laundry list of action XML.
Many thanks Jim (@_jims) for clarification on my recent post. Appreciate this.
Neil (@noisneil), even though Iām a little sad that you wouldnāt integrate my requested features, I think I understand your concern. Irs indeed a lot of functionality to add.
I wish I could help you out on that - so so youād have some less work to do it. But unfortunately Iām extremely busy at the moment.
Perhaps in the near future? (Just asking because it costs nothing than words).
It might help readability, but does it have any difference come execution? I seem to remember @peternlewis saying that all conditions were evaluated simultaneously and that there was no short-circuiting.
Ah, found it (or rather another reference to the same, since this was before my time):
So it seems to be a lot of work for little actual return.
With the way my brain works, it helps me think through the logic better if I place them in the order I mentioned above. This might also go back to my time writing C; in those days short circuit evaluation was important.
I think itās safe to say that Iām in the minority.
Then we're in a minority of two -- I think the same, do the same, and even used to recommend it for efficiency in KM until Peter put me straight about the lack of short-circuiting.
Most of us who had programmed using switch/case statements before using them in KM would probably add a lot to the total.
My bet would be that KM evaluates the conditions fast enough that the chosen style of testing conditions should be imperceptible in most circumstances. Even so, finding out about this encourages me to bear in mind always how switch/case conditions might be combined in order to make the list of conditions as short as possible.
It's the speed of the Condition-determining test(s) that matters. An "all must be true" will complete evaluation when the slowest test completes, an "any" will complete when the fastest is done (the macro moving on to the next block while the other tests complete in the background).
Thanks for sharing this gem.
