Community
Participate
Working Groups
I have table with Feature Column that has the following label expression: [if self.oclIsTypeOf(myDsl::SomeType) then self.name else '' endif /] when changing the expression to have multiple lines [if self.oclIsTypeOf(myDsl::SomeType) then self.name else '' endif /] Then the above code is replaced with the following (bad) code. [if self.oclIsTypeOf(myDsl::SomeType) ... as you can see everything after the first new line (\n) is truncated and replaced with "..." (see also https://www.eclipse.org/forums/index.php?t=msg&th=1071450&goto=1712258 )
Now there is no more "..." but the text is formatted to be on a single line. This come from TextWithContentProposalDialog.okPressed() which remove '\n' and '\t'.
A fix would be to have TextWithContentProposalDialog called with getDefaultFeatureAsText() instead of text and not have TextWithContentProposalDialog.okPressed() remove '\n' and '\t'. But there remains the issue that the Text is editable with the "...".
*** Bug 496196 has been marked as a duplicate of this bug. ***
Created attachment 266184 [details] Folded state
Created attachment 266185 [details] Expanded state
The draft patch at https://git.eclipse.org/r/88264, while not really a solution to this issue, is an attempt to replace the dialog box (modal dialogs tend to break the workflow) with a toggle to switch the interpreted expressions text fields between single or multi-line states. See the attached screenshots for what it looks like. I'm not completely convinced this would be the right approach, just posting it here as one possible approach.
New Gerrit change created: https://git.eclipse.org/r/88266
Created attachment 266186 [details] Embedded Unicode chars when displaying multi-line expressions with the second patch (In reply to Eclipse Genie from comment #7) > New Gerrit change created: https://git.eclipse.org/r/88266 This second patch is independant of the first one, but still a draft. It's only purpose is to clearly identify the offdending code which alters the value of the epxression entered by the specifier. By itself, if an expression has "\n" chars in it, it will be displayed on a single line with embedded Unicode placeholders (see attached screenshot).
Just noticed we didn't backport the temporary fix made on the maintanance branch. We should at least do that for 5.0.
I've pushed ca0caa99753116848bd0deb387dd15982c6d9999 on master, which disables the broken button. It's the same change that was made on the maintenance branch. Moving to 5.1 to re-evaluate if we can find a better solution to get the "multi-line editing" feature back, and if it's worth it.
*** Bug 562664 has been marked as a duplicate of this bug. ***
