Bugzilla – Full Text Bug Listing
| Summary: | [editor] In the OCLinEcore editor when accessing the attributes/properties of a parameter of an operation the editor shows an error. | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Simon harrer <simon.harrer> | ||||
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> | ||||
| Status: | CLOSED FIXED | QA Contact: | |||||
| Severity: | major | ||||||
| Priority: | P3 | CC: | ed | ||||
| Version: | unspecified | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 178906 [details]
Support for Parameters as symbol lookup targets
It's a pity this wasn't a couple of weeks earlier then it could have been in 3.0.1.
The problem is not the navigation from a parameter but the resolution of a parameter as a name at all.
Patch fixes it, but the code may all be overatken by 3.1.0. At least the test case should keep the new code honest.
Committed to HEAD for M3 and to maintenance branch for 3.0.2. Closing |
Build Identifier: 20100617-1415 I used the example of the extended library. There, just add the following method to the ecore model using OCLinEcore editor: operation showError(lib : Library[1]) : Boolean { body: self.name = lib.name; } As you can see, the "name" is detected as an error. However, the library has a name. This happens for any parameter. Reproducible: Always Steps to Reproduce: 1. Create the Extended Library Example for Ecore Models 2. Edit extlibrary.ecore and add the Method shown in the details 3. The name is detected as an error, but should be ok.