Community
Participate
Working Groups
Created attachment 264377 [details] Remove the <<Metaclass>> stereotypeapplication to see that the Block suddenly becomes Orange. Environment: Papyrus & SysML1.4 today's nightly Scenario (reproduction model attached): * You want to create a CSS style to color some elements based on stereotype properties. * Create a css file and include for instance: [appliedStereotypes~="SysML::Blocks::Block"][isEncapsulated] { fillColor : orange; } * Create a model that contains a Block, set its "isEncapsulated" property to true. * Apply the given stylesheet. * The Block is colored orange --> everything ok. * Now remove the Block stereotype and apply for instance "Metaclass" from the StandardProfile (just as a test, any other stereotype will do). * The element is not colored orange anymore --> ok. * Now add the Block stereotype again (with isEncapsulated=true), leaving the Metaclass stereotype in place. --> The element is _not_ colored orange --> Problem Conclusion: In case the stereotype field for which the CSS rule is filtering is not the first one in the list of stereotypeApplications, the rule fails to match. Already tried: Suppose you would leave out the property filter (isEncapsulted), the Block stereotype is found also if it is the second in the list. It therefore really seems to be the additional property filter that makes the difference. Potentially the cause is similar to #455620...
Confirmed. (Cumbersome) Workaround: Use the arrows in the profile tab of the properties to manually reorder the stereotype applications
The workaround is of course only valid if your CSS depends on properties of one stereotype only.
Reproduced on Neon.2.
Bug is in org.eclipse.papyrus.sysml14.diagram.common.css.dom.GMFSYSMLElementAdapter line 223 in doGetAttribute() (in org.eclipse.papyrus.sysml14.diagram.common 1.3.1). Rather than checking all stereotypes, it only checks the first and then returns null.