Community
Participate
Working Groups
Build Identifier: You can't drag a connection from a FixPointAnchor the way you can from a BoxRelativeAnchor. The corresponding EditPart, FixPointAnchorEditPart doesn't override getDragTracker the way BoxRelativeAnchorEditPart does. Reproducible: Always
Created attachment 198010 [details] Refactor getDragTracker Move getDragTracker up to AnchorEditPart, so both BoxRelativeAnchor and FixPointAnchor enjoy the dragging functionality.
What is the size of your FP anchor's GA? Could you please attach a screenshot?
I just did some testing with fixpoint anchors. In the current release of Graphiti it is possible to create references starting from a FPA. Currently it works without a patch.
I'm using a 10x10 ellipse as the GA, and when I start dragging from it, if it's related to a FPAnchor, the ellipse starts moving, but if it's related to a BRAnchor, it starts creating a connection. I'm creating an example I can attach to the bug, maybe I'm just doing it wrong.
Which tool are making use of? Is it the selection tool? In this case the bug has to turned around. The selection tool must not draw connections...
I'm using no tool, I'm just dragging the mouse from the Anchor. In my Feature Provider I override getDragAndDropFeatures like this: @Override public IFeature[] getDragAndDropFeatures(IPictogramElementContext context) { // simply return all create connection features return getCreateConnectionFeatures(); }
Created attachment 198078 [details] Minimal editor reproducing This is a sample graphiti editor that creates a single rectangle, with two boxes. The relative can be dragged from, the fixed one cannot.
Created attachment 198079 [details] Runtime workspace project Use this project in the target runtime wks, and open "newDiagram.diagram" with the "MyEditor" editor. Two circles will show, a blue BRAnchor, and a red FPAnchor. If you drag form the first, it will try to create a connection. If you drag from the second, the anchor itself will start moving.
(In reply to comment #6) > I'm using no tool, I'm just dragging the mouse from the Anchor. In my Feature > Provider I override getDragAndDropFeatures like this: > > @Override > public IFeature[] getDragAndDropFeatures(IPictogramElementContext context) { > // simply return all create connection features > return getCreateConnectionFeatures(); > } No tool means selection tool, I guess. Connections should only be created with a connection tool selected from the palette. Creating connections with the selection tool are disabled in HEAD.
(In reply to comment #9) > (In reply to comment #6) > > I'm using no tool, I'm just dragging the mouse from the Anchor. In my Feature > > Provider I override getDragAndDropFeatures like this: > > > > @Override > > public IFeature[] getDragAndDropFeatures(IPictogramElementContext context) { > > // simply return all create connection features > > return getCreateConnectionFeatures(); > > } > > No tool means selection tool, I guess. > Connections should only be created with a connection tool selected from the > palette. Creating connections with the selection tool are disabled in HEAD. We have no palette in our diagram, since the nodes can't be modified, only the relations among them. The relations are created by dragging from anchors. If I've understood you right, you've removed that functionality. Quoting the javadoc from IFeatureProvider.getDragAndDropFeatures, "if the user should be able to create connections directly from a pictogram element without using the connection tool you can provide an array of features." The getDragAndDropFeatures method from the IFeatureProvider interface is only called from the getDragTracker method in the BoxRelativeAnchorEditPart class. However, when a tool from the palette is selected, the getDragTracker method you've modified in cvs isn't even invoked, so getDragAndDropFeatures never gets called. Please reevaluate your last commit. You're just removing existing functionality, not fixing anything.
I just did the rollback in HEAD. - Not really happy about that. Read-only editors without palette are okay, but diagram editing without palette....
(In reply to comment #11) > I just did the rollback in HEAD. - Not really happy about that. > Read-only editors without palette are okay, but diagram editing without > palette.... Thank you, Christian. Is there any chance you may change FPAnchorEditPart so it provides the same functionality that BRAnchorEditPart does?
Targeted for Juno
Thanks for the suggestion and contribution! I unified the functionality as you suggested. While having a closer look, it turned out that the different anchor EditPart functionalities were indeed equal, so I introduced just one EditPart (AdvancedAnchorEditPart) that holds all the functionality and offers it for all anchor types. Checked in to head and pushed to Eclipse: commit 2998206489c6883a255033ce10498cdb361e5db0 Author: mwenz <michael.wenz@sap.com> 2011-11-24 14:03:20 Committer: mwenz <michael.wenz@sap.com> 2011-11-24 14:14:58 Parent: b83a0298b56f8044ed4df45ac80702417283cff7 (New image for Chapter "Scenario Description") Branches: origin/master, master
Bookkeeping: Set target release
Part of Graphiti 0.9.0 (Eclipse Juno)
