Bugzilla – Full Text Bug Listing
| Summary: | [General] IllegalArgumentException: An EditPart has to be selectable... | ||
|---|---|---|---|
| Product: | [Modeling] Papyrus | Reporter: | Yann Tanguy <yann.tanguy> |
| Component: | Core | Assignee: | Project Inbox <mdt-papyrus-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | cletavernier, Patrick.Tessier, vincent.lorenzo |
| Version: | 0.8.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Bug Depends on: | 352994 | ||
| Bug Blocks: | 348549, 350423, 350884, 351419 | ||
|
Description
Yann Tanguy
To reproduce : - A reproductible JUnit test has been added in BlockDefinitionDiagram tests (compartment.setFocus(true)). Related GEF bug: 333865: Exception thrown when deleting several edit parts with GEF 3.7 https://bugs.eclipse.org/bugs/show_bug.cgi?id=333865 (In reply to comment #2) > Related GEF bug: > > 333865: Exception thrown when deleting several edit parts with GEF 3.7 > https://bugs.eclipse.org/bugs/show_bug.cgi?id=333865 349124: java.lang.IllegalArgumentException thrown when selecting ToolEntryEditPart in PaletteStack https://bugs.eclipse.org/bugs/show_bug.cgi?id=349124 As far as I understand this has something to do with change in selection methods implementation (see. comments in previous bug) and is supposed to be fixed in 3.7 SR1. TODO: - Make sure as soon as possible that this issue is also fixed for Papyrus in 3.7 SR1 - Make sure as soon as possible that the GEF fix is sufficient and does not also requires a corrective action in GMF Runtime... the selection methods have been changed as part of bug #330859 GMF Tooling generates ChildNodeLabels edit parts with an inheritance to org.eclipse.gmf.runtime.diagram.ui.editparts.CompartmentEditPart. Pretty strange as ChildNodeLabels are definitely not compartments... Anyway, the problem here occurs while trying to select such ChildNodeLabels (for instance right after creation), in case their owner is not selected. In CompartmentEditPart, the selection behavior does only allow the compartment to be selected if its owner already has the focus. This ensures the a click anywhere on a element without focus result in the selection of the element, not one of its compartments. As ChildNodeLabels inherits from CompartmentEditPart they inherit the same behavior. On creation, the creation tool tries to select the new object after creation. The problem is that when a ChildLabelNode is created whereas its owner doesn't have the focus, the newly created element cannot be selected (isSelectable from CompartmentEditPart implementation will return null). Before GEF 3.7, this was probably ignored, but some changes in GEF 3.7 now throw an exception in any attempt to set focus or selection on an edit part which is not selectable which is the case here... In r5124 : Fix for BDD - AbstractElementChildLabelEditPart now inherits from GraphicalEditPart instead of UMLCompartmentEditPart or CompartmentEditPart (BDD Specific ChildLabelNodes) - EditPart replacement for Slot element from the ClassDiagram (not corrected in ClassDiagram yet). - NamedElementLabelNameEditPart renamed into NamedElementNodeLabelNameEditPart to avoid possible confusion, this is a node label, not a ChildLabelNode. (In reply to comment #5) > In r5124 : Fix for BDD > - AbstractElementChildLabelEditPart now inherits from GraphicalEditPart instead > of UMLCompartmentEditPart or CompartmentEditPart (BDD Specific ChildLabelNodes) > - EditPart replacement for Slot element from the ClassDiagram (not corrected in > ClassDiagram yet). > > - NamedElementLabelNameEditPart renamed into NamedElementNodeLabelNameEditPart > to avoid possible confusion, this is a node label, not a ChildLabelNode. Trunk merge in r5127. (In reply to comment #1) > To reproduce : > - A reproductible JUnit test has been added in BlockDefinitionDiagram tests > (compartment.setFocus(true)). Test modified in BDD (r5137) : see oep.sysml.diagram.blockdefinition.tests.creation.TestNodeCreationOnDiagram::dropExceptionToFix_bug348549(). The same bug appears when creating Operations or Properties in a Class, in the Class Diagram. r5433 : A similar fix has been applied : the implementation of the isSelectable() method from the UMLCompartmentEditPart has been changed. This fix has side effects : you can know select an operation (or a property) without selecting its class beforehand. Therefore, the selection area for a Class has been reduced, which may lead to difficulties for moving or resizing a Class (Or other elements with a similar behavior) Still valid e.g. in the Profile Diagram, when creating Properties I haven't seen this bug for a while I close the task |