Eclipse Community Forums: GEF » REPOST: Marquee + bendpoint selection/move

Home » Eclipse Projects » GEF » REPOST: Marquee + bendpoint selection/move

REPOST: Marquee + bendpoint selection/move [message #144450]

Mon, 26 July 2004 15:25

Eclipse User

I wondered if anyone had thoughts on this, I'd really like to try and get
this issue resolved.

> I'm trying to implement functionality whereby when multiple nodes are
> selected and moved (via the marquee tool for example) then any absolute
> bendpoints which live on the connections between two nodes being moved,
> are also moved. This question has been asked a number of times before,
> and I have been following the following suggestion made by Randy:

> - Simple! When the class get's a changeBoundsRequest, have it forward some
> - "move bendpoints request" to all of it's source connections (source
> - connections are the ones going out of the node). You can do this
> - conditionally only if the target node is also moving (see
> - ChangeBoundsRequest.getEditParts()). You could test for the condition
> - either on the connection, or at the time when you decide to forward to
> the
> - connection.

> I think I have done what is being suggested here. When a
> changeBoundsRequest is received by the node then it iterates through all
> the connections it is the source for and test to see if the target node is
> also being moved. If this is the case, then REQ_MOVE_BENDPOINT requests
> are constructed and the appropriate commands queued. This works, but the
> problem is that the new position is the new position of the node (set
> using request.setLocation(..)) not of the bendpoint.

> Any suggestion on how I can work out the bendpoints new position? Or
> alternatively a better way to implement this functionality?

> James

Re: REPOST: Marquee + bendpoint selection/move [message #144606 is a reply to message #144450]

Tue, 27 July 2004 14:07

Eclipse User

Originally posted by: none.us.ibm.com

> > I'm trying to implement functionality whereby when multiple nodes are
> > selected and moved (via the marquee tool for example) then any absolute
> > bendpoints which live on the connections between two nodes being moved,
> > are also moved. This question has been asked a number of times before,
> > and I have been following the following suggestion made by Randy:
>
> > - Simple! When the class get's a changeBoundsRequest, have it forward
some
> > - "move bendpoints request" to all of it's source connections (source
> > - connections are the ones going out of the node). You can do this
> > - conditionally only if the target node is also moving (see
> > - ChangeBoundsRequest.getEditParts()). You could test for the condition
> > - either on the connection, or at the time when you decide to forward to
> > the
> > - connection.
>
> > I think I have done what is being suggested here. When a
> > changeBoundsRequest is received by the node then it iterates through all
> > the connections it is the source for and test to see if the target node
is
> > also being moved. If this is the case, then REQ_MOVE_BENDPOINT requests
> > are constructed and the appropriate commands queued. This works, but
the
> > problem is that the new position is the new position of the node (set
> > using request.setLocation(..)) not of the bendpoint.

So use request.getMoveDelta(), and apply it to the current bendpoint
location.

>
> > Any suggestion on how I can work out the bendpoints new position? Or
> > alternatively a better way to implement this functionality?

An alternative way would be to have the drag tracker determine which
connection editparts should be asked, and have it ask the connection
directly. You may be able to simply override getOperationSet() and then
just add support for MOVE in the connection editparts. Or you could make up
a new request ID specifically which is probably cleaner.

>
> > James
>

Re: REPOST: Marquee + bendpoint selection/move [message #144700 is a reply to message #144606]

Tue, 27 July 2004 17:26

Eclipse User

> > > I think I have done what is being suggested here. When a
> > > changeBoundsRequest is received by the node then it iterates through all
> > > the connections it is the source for and test to see if the target node
> is
> > > also being moved. If this is the case, then REQ_MOVE_BENDPOINT requests
> > > are constructed and the appropriate commands queued. This works, but
> the
> > > problem is that the new position is the new position of the node (set
> > > using request.setLocation(..)) not of the bendpoint.

> So use request.getMoveDelta(), and apply it to the current bendpoint
> location.

Thanks Randy - it so obvious when you point it out!

One further question. I have an XYLayoutEditPolicy set on the parent of
the nodes in question. When the nodes are moved - this policy handles the
request. I would have expected that request.getEditParts() returns a list
of all the nodes receiving the request (i.e. if I remove four nodes
simultaneously, then this list would of size four). However the value is
always one regardless of how many nodes are being dragged, why is this?

James

Re: REPOST: Marquee + bendpoint selection/move [message #144872 is a reply to message #144700]

Wed, 28 July 2004 09:46

Eclipse User

Originally posted by: none.us.ibm.com

This is because each child individually receives the move request, and
forward it on to its parent for itself only. The plan was to change this so
that the selection set was split up into individual sets of children with
the same parent, and then ask each parent for the necessary commands. But
no one has really required this so it hasn't happened. For compatibility we
would probably have to make this an option on DragEditPartsTracker and not
the default.

"James Willans" <jwillans@cs.york.ac.uk> wrote in message
news:ce6h98$63b$1@eclipse.org...
>
> > > > I think I have done what is being suggested here. When a
> > > > changeBoundsRequest is received by the node then it iterates through
all
> > > > the connections it is the source for and test to see if the target
node
> > is
> > > > also being moved. If this is the case, then REQ_MOVE_BENDPOINT
requests
> > > > are constructed and the appropriate commands queued. This works,
but
> > the
> > > > problem is that the new position is the new position of the node
(set
> > > > using request.setLocation(..)) not of the bendpoint.
>
> > So use request.getMoveDelta(), and apply it to the current bendpoint
> > location.
>
> Thanks Randy - it so obvious when you point it out!
>
> One further question. I have an XYLayoutEditPolicy set on the parent of
> the nodes in question. When the nodes are moved - this policy handles the
> request. I would have expected that request.getEditParts() returns a list
> of all the nodes receiving the request (i.e. if I remove four nodes
> simultaneously, then this list would of size four). However the value is
> always one regardless of how many nodes are being dragged, why is this?
>
> James
>

Re: REPOST: Marquee + bendpoint selection/move [message #145045 is a reply to message #144872]

Wed, 28 July 2004 17:17

Eclipse User

Okay thanks. So how can I calculate which other nodes are being
simultaneously being moved?

James

Randy Hudson wrote:

> This is because each child individually receives the move request, and
> forward it on to its parent for itself only. The plan was to change this so
> that the selection set was split up into individual sets of children with
> the same parent, and then ask each parent for the necessary commands. But
> no one has really required this so it hasn't happened. For compatibility we
> would probably have to make this an option on DragEditPartsTracker and not
> the default.

> "James Willans" <jwillans@cs.york.ac.uk> wrote in message
> news:ce6h98$63b$1@eclipse.org...
> >
> > > > > I think I have done what is being suggested here. When a
> > > > > changeBoundsRequest is received by the node then it iterates through
> all
> > > > > the connections it is the source for and test to see if the target
> node
> > > is
> > > > > also being moved. If this is the case, then REQ_MOVE_BENDPOINT
> requests
> > > > > are constructed and the appropriate commands queued. This works,
> but
> > > the
> > > > > problem is that the new position is the new position of the node
> (set
> > > > > using request.setLocation(..)) not of the bendpoint.
> >
> > > So use request.getMoveDelta(), and apply it to the current bendpoint
> > > location.
> >
> > Thanks Randy - it so obvious when you point it out!
> >
> > One further question. I have an XYLayoutEditPolicy set on the parent of
> > the nodes in question. When the nodes are moved - this policy handles the
> > request. I would have expected that request.getEditParts() returns a list
> > of all the nodes receiving the request (i.e. if I remove four nodes
> > simultaneously, then this list would of size four). However the value is
> > always one regardless of how many nodes are being dragged, why is this?
> >
> > James
> >

Re: REPOST: Marquee + bendpoint selection/move [message #145537 is a reply to message #145045]

Thu, 29 July 2004 13:03

Eclipse User

Originally posted by: none.us.ibm.com

You only want to do this one time, not for every node being dragged. I
would suggest doing it in the drag tracker and extending getCommand to
include the move bendpoints contribution.

"James Willans" <jwillans@cs.york.ac.uk> wrote in message
news:ce954j$gu2$1@eclipse.org...
> Okay thanks. So how can I calculate which other nodes are being
> simultaneously being moved?
>
> James
>
> Randy Hudson wrote:
>
> > This is because each child individually receives the move request, and
> > forward it on to its parent for itself only. The plan was to change
this so
> > that the selection set was split up into individual sets of children
with
> > the same parent, and then ask each parent for the necessary commands.
But
> > no one has really required this so it hasn't happened. For
compatibility we
> > would probably have to make this an option on DragEditPartsTracker and
not
> > the default.

Previous Topic:	a toolEntry stays pushed
Next Topic:	a toolEntry that call a method

Goto Forum:

-=] Back to Top [=-

Current Time: Sun Jul 06 12:06:27 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter