Bug 509268

Description Peter Cigehn 2016-12-15 04:59:16 EST

Now when base Papyrus have introduced the support "inline editing" of elements in the model explorer (as tracked by Bug 476629) directly after they have been created, causes some issues specifically for protocol message parameters.

Since the embedded editor from base Papyrus is a generic editor for parameters, the embedded editor is a rather "complex" edit providing lots of features, most of which are not applicable to protocol message parameters, which in general are much more limited than parameters of an ordinary operation.

It also seem that the embedded editor handles the (explicit) setting of visibility in a not wanted way, i.e. it explicitly sets visibility to public causing the visibility annotation to be shown, i.e. the green + is now shown. Normally parameters are created without explicitly setting visibility, causing some rather inconsistent experience when parameters are created in different, where some parameters have the green + annotation whereas others don't have it.

Another major issue is that whenever a protocol message parameter is selected to be typed by primitive type from the AnciCLibrary, the primitive type library associated with the C++ default language, then an error marker appears on the protocol message parameter complaining about "A Parameter with invalid text string found", and also an additional comment element is created in the semantic model with the text string (which is extremely confusing).

Steps to reproduce:

1) Create a UML-RT model
2) Select the root element of this model and assign the default language C++ on the Language tab in the properties view
3) Create a protocol in this model
3) Create a protocol message in this protocol
4) Create a parameter for this protocol message using the UML-RT new child menu in the model explorer
5) Select '*' as type
6) Observe how the created parameter is selected and available in edit mode in the model explorer.
7) The user can now do (at least) three different things: 1) Just click somewhere else (which maybe will be the most common scenario), e.g. creating further parameters, 2) press Esc (if they feel they want to abort the editing) or 3) press Enter (if they feel they want to confirm the editing). 
8) First scenario: Click somewhere else, e.g. simply right click and create another parameter.
9) Observe how the parameter now gets the green + annotation, indicating the its visibility was explicitly set.
10) Create another parameter using the UML-RT new child menu in the model explorer but now choose scenario 2) and instead press Esc to abort the editing.
11) Observe how the parameter now does *not* get the green + annotation, indicating the its visibility is left unset (which still have the semantic that visibility is public). This is also how the parameter by default should be created, i.e. visibility shall be left unset. Compare with creating a parameter using the parameter table in the properties view for the protocol message, where parameters are created with visibility unset, and thus does not have the green + annotation in the model explorer.
12) Now create yet one more parameter using the UML-RT new child menu
13) Now select any of the primitive types, e.g. int or long
14) Try scenario 1) or 3), confirming the edit.
15) Observer how an error marker appears on the created parameter and an error is logged in the "Model Validation" view, stating "A Parameter with invalid string found". Also observe how a comment element (owned by the parameter) is created in the model with the string as its contents (this I find extremely confusing and strange that new semantic model elements are created in the model due that the parsing of the string failed for some reason
16) If instead scenario 2) was used, and the user press Esc, then parameter is created fine as expected, and no error marker appears on the parameter.

The user experience of all this is very confusing and inconsistent. 

The suggestions it to simple have the basic name based editor for protocol message parameters, at least in the short term, where you basically only edit the name of the protocol message parameter. Since we have the parameter table in the properties view with content assist support for selecting the type, this should be sufficient.

If there is a strong need for a more complex embedded editor, e.g. also for selecting the type, then a slightly modified/simplified embedded editor shall be provided for protocol message parameters. It does not need to handle visibility, direction, and all the other aspects currently handled (and also partly confusing/incorrect when it specifically comes to visibility). The only thing that the embedded editor for protocol message parameters should need to handle is name and type, i.e. the same limited sets of properties that we have on the UML-RT tab for a protocol message parameter. This simplified/modified embedded editor then of course also needs to properly handle the case when selecting types from the AnsiCLibrary without causing the error marker to appear.

The current embedded parameter editor should *only* be applicable for parameters of an ordinary operation.