Community
Participate
Working Groups
Steps to reproduce: Create a UML model with a class and add a property 'prop' to that class typed by a Primitive type (for instance) In the properties view, click on the '+' button of the DefaultValue field. Select OpaqueExpression In the language field, "select" OCL In the expression field, type self.prop -> The expression is 'rejected' by the parser (Unresolved Property OCLInvalid::prop), yet it is valid OCL (although a partial expression) Press OK (anyway). Now Press the 'Edit' (pen) symbol of the DefaultValue field. You will notice that the expression is now parsed/interpreted correctly and the 'tab completion' works as expected. (So it seems like the context is not set yet/correctly when initalizing the opaque expression)
(In reply to Klaas Gadeyne from comment #0) > (So it seems like the context is not set yet/correctly when initalizing the > opaque expression) The repro steps strongly suggest that OCL is initially asked to edit an OpaqueExpression with a null eContainer(). Subsequently it has one. So just add the OpaqueExpression with empty string content to the Property before invoking the OCL parser.
Still present in Neon.2, and not mac specific. @Benoit, do you have a clue where to look for solving this in the papyrus sources? TIA
(In reply to Ed Willink from comment #1) > (In reply to Klaas Gadeyne from comment #0) > > (So it seems like the context is not set yet/correctly when initalizing the > > opaque expression) > > The repro steps strongly suggest that OCL is initially asked to edit an > OpaqueExpression with a null eContainer(). Subsequently it has one. So just > add the OpaqueExpression with empty string content to the Property before > invoking the OCL parser. That is exactly the problem. It is a fundamental limitation/flaw in the dialog-based creation workflow that the dialog edits a new object before it is attached to the model. Papyrus-RT customizes this to add the new element immediately, because otherwise the required stereotypes could not be applied, without notifying the UI so that the new element only appears in the explorer, diagrams, etc. after the dialog is completed. Probably Papyrus should do this.
@Christian: It seems to me that you have a generic solution. Is there a known limitation so that this patch was integrated in Papyrus-RT instead of Papyrus-core ?
(In reply to Benoit Maggi from comment #4) > @Christian: It seems to me that you have a generic solution. Is there a > known limitation so that this patch was integrated in Papyrus-RT instead of > Papyrus-core ? Yes. It isn't a generic solution and it depends on some other Papyrus-RT-specific APIs to ensure that the object being created isn't prematurely exposed in various places in the UI, all by different means. This is not an enhancement that I would propose for the Neon.x maintenance stream because it has fairly widespread impact on the UI. And at the time, we were planning that the Papyrus 1.0 would be released on Papyrus Neon.1. Things have changed since then. If Papyrus is interested in it, we should try for something more generic in 3.0. Probably it could solve more problems than this OCL context issue.
