Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 320829

Summary:

[Property tab] Stereotype attributes cannot be modified

Product:

[Modeling] Papyrus

Reporter:

Ansgar Radermacher <ansgar.radermacher>

Component:

Core

Assignee:

Project Inbox <mdt-papyrus-inbox>

Status:

RESOLVED FIXED

QA Contact:

Severity:

major

Priority:

CC:

rschnekenburger

Version:

unspecified

Flags:

sebastien.gerard: iplog-

Target Milestone:

---

Hardware:

OS:

Linux

Whiteboard:

Attachments:

Description	Flags
Simple workaround returning the EditingDomain via EditorUtils	sebastien.gerard: iplog+
Same workaround as before, additional fix to ensure always consistency between value shown in left ("Applied stereotype") and right ("Property values") panes	sebastien.gerard: iplog+

Description Ansgar Radermacher

2010-07-24 17:32:14 EDT

Build Identifier: 

It is not possible to set stereotype attributes with [0..1] or [0..*] multiplicity. A null-pointer exception is triggered.

It seems that a very recent Papyrus modification (not yet analyzed which) has the effect that the operation "setDomain" of class PropertyComposite (in org.eclipse.papyrus.profile.ui.compositesformodel) is no longer called and in turn the domain is not initialized for this class.

Reproducible: Always

Steps to Reproduce:
1. Select a model element
2. Apply a stereotype which has [0..1] or [0..*] attributes
3. try add or remove a value

Comment 1 Ansgar Radermacher

2010-07-24 17:35:51 EDT

Created attachment 175165 [details]
Simple workaround returning the EditingDomain via EditorUtils

Please verify that the error is reproducible and fixed with the workaround. Is it possible to integrate the workaround into the release that has just been made?

Comment 2 Ansgar Radermacher

2010-07-24 18:35:06 EDT

Created attachment 175167 [details]
Same workaround as before, additional fix to ensure always consistency between value shown in left ("Applied stereotype") and right ("Property values") panes

In the current version, fields on the left and right side can become inconsistent. An example is to add a value to a stereotype attribute and this addition fails on the model side with an exception. The new value was added on the right side but not on the left. The exception due to the non-initialized domain made me aware of the problem, but it can also be triggered if the user tries to add for instance values to a derived attribute or if the derived attribute evaluation has side effect of changing other attributes.

Comment 3 Ansgar Radermacher

2010-09-02 07:22:19 EDT

Applied patches fix the problem.