Proposal for a specific CASE element editor

[codemanyak]

For the creation of (and even more for the manipulation of existing) CASE elements, a dedicated editor layout might be more self-explaining and helpful:

The multi-line text is not unintelligible and has worked for the entire Structorizer history, of course, but it had a specific weakness: What happens with existing branches if we insert / delete / reorder lines?
The new editor could address this via a controlled line manipulation in the branch selector table (via the coloured-icon buttons). The first column would keep track of the original line numbers and if the check box "Move branches" is selected (should be disabled for a new CASE element, of course) on committing then the existing branches would be rearranged according to the new line number permutation. Inserted new lines would not get such line numbers - the respective field remains empty. The first column wouldn't be editable therefore, just the second table column.
Via the checkbox "Default branch" it would be more obvious what is to happen. The label field would be disabled in case the checkbox is not selected (internally, the "%" line will be appended then).
On the Element level, nothing would change: It would still be the same text content, it would just be converted to and fro on editing.

[codemanyak]

A disadvantage of the proposed editor would be that it doesn't easily allow broken lines (line continuations after a backslash). Formally, the user might insert "\n" in a line to force a line break on conversion, though (Conversely, broken lines would be converted this way when forged into the editor fields.

[codemanyak]

A prototype (with different icons - I reused the ones for elements) is ready. For the experienced user, however, the original editor is faster to use. So the use of he new editor should be optional.
I think, a respective checkbox could be added to the Structure Preferences (there is space enough at the bottom of the CASE area):

[codemanyak]

Eventual design:

[codemanyak]

The new editor has way more potential that ought to be used:

• Instead of numbering all existing branches, this could be restricted to non-empty existing branches.
• Orphaned branch numbers (e.g. by having deleted the associated line) cannot be reactivated (e.g. associated to a new line) in the current version. This could be mended by allowing to edit the first column via a choice list (non-editable combobox) offering the numbers of all orphaned non-empty branches. On the other hand, an empty string might be among the choice list in order to loosen a branch bond.
• There could be buttons to merge selected rows (while no more than one non-empty branch is involved) and to split a row with more than one selector. An associated branch number would have to be inherited by all resulting rows such that the branch will be copied on commit.
• The editor might try to infer the data type of the discriminator expression (e.g. the choice variable):
  • In case it is an enumerator type, the completion of the set of lines to all enumerator values still not contained in the existing lines may be offered (as well as the elimination of all superfluous lines, i.e. those without a member constant and no associated relevant branch).
  • In case of a structured type, a warning flag would be set, such that the function described next could report it.
• A check for conflicts among lines, for non-evaluable selector expressions and, the occurrence of orphaned branches, a discriminator of a structured data type etc. could be implemented.

The layout might look like this: