Bugzilla – Full Text Bug Listing
| Summary: | [console] Pressing the Enter key to select a completion proposal executes the expression | ||
|---|---|---|---|
| Product: | [Modeling] OCL | Reporter: | Adolfo Sanchez-Barbudo Herrera <adolfosbh> |
| Component: | Core | Assignee: | OCL Inbox <mdt-ocl-inbox> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | ed |
| Version: | 3.1.0 | ||
| Target Milestone: | RC1 | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Adolfo Sanchez-Barbudo Herrera
I suspect that this is closely related to Bug 340533 which I originally logged against MDT/OCL. Most of these issues seem to be XText ones. Always worth trying to reprodyce them with an Xtext only context. THough trying to reproduce it I can't see anything wrong and cannot understand waht you mean by "execute". GUI bugs night very precise description. What was selected. NB also that completion in the JDT editor is pretty bad too. Ed, The problem is so common/usual I thought you had experimented and/or followed and no test metamodel, instance and detailed description were necessary. When I said "executed", I meant "evaluated/interpreted" by the Xtext Console. I'll try it again with more precise information with very simple example steps: 1. Create an ecore with a class "Person". 3. I select the Person and Open the Xtext Console 5. I write "self.na" + ctrl + space. 6. The "name" attribute, among other proposals, appears in a popup dialog/box. 7. I use the "up" and "down" key to focus the selection on the "name" attribute. 8. I press the "Enter" key to select the proposal. 9. An incorrect expression is executed/evaluated/interpreted with the following result: Evaluating: self.na Results: Parsing failure "Unresolved property 'na' for 'Ecore::ecore::EClass value'" 10. The area which the user uses to write the OCL expression is cleared. In step 9, I wouldn't expect any OCL expression evaluation. Instead, in step 10, I would expect to have the letter "name" (the selected attribute) in the area the user uses to write the OCL expression. More useful info for you: - The expected behaviour works fine in Xtext, JDT and any other OCL Editor. The problem is in the console which evaluates the incomplete expression instead of just replacing the partial-text by the selected completion proposal. - The original OCL console works as I had expected. - If I use the mouse to select the completion proposal, the Xtext Console works fine (we have the expected behavior). - If I write self.name I receive the expected result: Evaluating: self.name Results: 'Person' - I've re-checked that I'm using the proper examples (this morning build): org.eclipse.ocl.examples feature - v20110510-0531 Regards, Adolfo. Sorry, I assumed Completion Proposals were for the main editors and so was confused by 'execution'. The completion works for arrow navigation and select. The problem is that Enter is being absorbed to execute the current text. There was code that I didn't understand about completion-assists. Now I do. Enter should not execute when completion assist is active. If you fancy fixing this, reinstate the if (!input.isContentAssistActive() guards from org.eclipse.ocl.examples.interpreter.OclConsolePage$InputKeyListener in org.eclipse.ocl.examples.xtext.console.OclConsolePage$InputKeyListener. The bit I don't know how to do is the implementation of isContentAssistActive to interrogate the Xtext content-assist rather than some magic timeout on the OCLSyntaxHelper one. Rather than preventing the InputKeyListener doing the wrong thing and finding out out how the InputKeyListener can tell that it's doing the wrong thing, it may be better to: Inject a derived CompletionAssist 'handler' (and probably a QuickFix 'handler' too) that remove and then add the key listener around their assisting functionality. Completion proposals don't seem to work at all in the console any more. (In reply to comment #5) > Completion proposals don't seem to work at all in the console any more. Fixed at about M7. Problem is that InputKeyListyener must be suppressed during CompletionAssist. Thanks to the wonders of DI a deriveed class can be introduced to interrogate the protected method, rtaher than the fragile independent timeout in the old console. Pushed to master for RC1. CLOSED after more than a year in RESOLVED state. and CLOSE |