Eclipse Community Forums: GEF » Drag and Drop creation

Home » Eclipse Projects » GEF » Drag and Drop creation

Tue, 28 January 2003 05:18

Eclipse User

Originally posted by: g.wagenknecht.intershop.de

The new creation via drag and drop is good. How can I influence if a drop is
possible or not? The default implementation recognizes connections and
disallow drop over connections. But I want to change this to disallow drop
over figures (edit parts), too.

Thanks, Gunnar

Re: Drag and Drop creation [message #58520 is a reply to message #58513]

Tue, 28 January 2003 05:40

Eclipse User

Originally posted by: g.wagenknecht.intershop.de

Addition:

I asume the my CreateCommand is responsible if it is possible or not. Could
it be, that this command is executed with another layer? I'm unsure because
the CreateCommand successfully disallow creation over existing edit parts if
used via the creation tool and allows over connection edit parts. When using
the my CreateCommand via the creation dragger it works vice versa.

Cu, Gunnar

Re: Drag and Drop creation [message #58529 is a reply to message #58520]

Tue, 28 January 2003 05:50

Eclipse User

This suggestion from Eric Bordeau worked for me.

Override getTargetEditPart in the XYLayoutPolicy. Check for a REQ_CREATE
and in this case get the host EditPart and check whether a drop is possible
if it is return the EditPart otherwise return null. For all other request
simply let XYLayoutPolicy handle getTargetEditPart.

Hope this helps,

John.

"Gunnar Wagenknecht" <g.wagenknecht@intershop.de> wrote in message
news:b15lgd$hq9$1@rogue.oti.com...
>
> Addition:
>
> I asume the my CreateCommand is responsible if it is possible or not.
Could
> it be, that this command is executed with another layer? I'm unsure
because
> the CreateCommand successfully disallow creation over existing edit parts
if
> used via the creation tool and allows over connection edit parts. When
using
> the my CreateCommand via the creation dragger it works vice versa.
>
> Cu, Gunnar
>
>

Re: Drag and Drop creation [message #58541 is a reply to message #58529]

Tue, 28 January 2003 06:56

Eclipse User

Originally posted by: g.wagenknecht.intershop.de

"John Howard" <john.howard9@btinternet.com> schrieb im Newsbeitrag
news:b15m7u$ial$1@rogue.oti.com...

> Override getTargetEditPart in the XYLayoutPolicy. Check for a REQ_CREATE
> and in this case get the host EditPart and check whether a drop is
possible
> if it is return the EditPart otherwise return null. For all other request
> simply let XYLayoutPolicy handle getTargetEditPart.

Mhm, I'm confused. This is not really intuitive. Normally I expect the
Command#canExecute is checked. All other commands behave this way.

I'm also wondering why the default implementation disallow dropping over
connections, although the default implementation of #getTargetEditPart
doesn't check for this.

The general rule was IMHO that a command can't be executed if a
getConstraint(...) returns null.

Cu, Gunnar

Re: Drag and Drop creation [message #58602 is a reply to message #58541]

Tue, 28 January 2003 07:28

Eclipse User

You could handle it in the CreateCommand, but the issue would be no
feedback. The indication would be that you are allowed to drop up to the
point you try to drop the item. So, I think the CreateCommand is to late in
the process.

The other place where you could stop the drop and get the feedback is in
AbstractTransferDropTargetListener#isEnabled() which may be how the disallow
over connections is handled.

I agree I doesn't feel particularly intuitive because what you are really
saying using this method is that there is no edit part and the
AbstractTransferDropTargetListener#isEnabled() is then treating this as a
can't drop.

Cheers,

John.

"Gunnar Wagenknecht" <g.wagenknecht@intershop.de> wrote in message
news:b15pum$l2j$1@rogue.oti.com...
>
> "John Howard" <john.howard9@btinternet.com> schrieb im Newsbeitrag
> news:b15m7u$ial$1@rogue.oti.com...
>
> > Override getTargetEditPart in the XYLayoutPolicy. Check for a
REQ_CREATE
> > and in this case get the host EditPart and check whether a drop is
> possible
> > if it is return the EditPart otherwise return null. For all other
request
> > simply let XYLayoutPolicy handle getTargetEditPart.
>
> Mhm, I'm confused. This is not really intuitive. Normally I expect the
> Command#canExecute is checked. All other commands behave this way.
>
> I'm also wondering why the default implementation disallow dropping over
> connections, although the default implementation of #getTargetEditPart
> doesn't check for this.
>
> The general rule was IMHO that a command can't be executed if a
> getConstraint(...) returns null.
>
> Cu, Gunnar
>
>

Re: Drag and Drop creation [message #59021 is a reply to message #58520]

Tue, 28 January 2003 17:41

Eclipse User

Originally posted by: none.us.ibm.com

This is an interesting question. You are right that it is inconsistent.
What you want is a NOT cursor. There are two ways to do this. One, the
drop listener is still active because there is a target editpart, and
handleDragOver changes the Drop detail to DND.DROP_NONE because the command
cannot be executed or is null. Two, the drop listener returns false in
isEnabled(..)

The reason we do not rely on a Command is that during most DND operations,
the DropEvent.data field is set to null, so it possible that the Command is
never executable until handleDrop() is called, at which point hte
DropEvent.data field has the data.

"Gunnar Wagenknecht" <g.wagenknecht@intershop.de> wrote in message
news:b15lgd$hq9$1@rogue.oti.com...
>
> Addition:
>
> I asume the my CreateCommand is responsible if it is possible or not.
Could
> it be, that this command is executed with another layer? I'm unsure
because
> the CreateCommand successfully disallow creation over existing edit parts
if
> used via the creation tool and allows over connection edit parts. When
using
> the my CreateCommand via the creation dragger it works vice versa.
>
> Cu, Gunnar
>
>

Re: Drag and Drop creation [message #60236 is a reply to message #59021]

Thu, 30 January 2003 14:35

Eclipse User

Originally posted by: g.wagenknecht.planet-wagenknecht.de

"Randy Hudson" <none@us.ibm.com> schrieb im Newsbeitrag
news:b16vvm$lu2$1@rogue.oti.com...
> This is an interesting question. You are right that it is inconsistent.
> What you want is a NOT cursor. There are two ways to do this. One, the
> drop listener is still active because there is a target editpart, and
> handleDragOver changes the Drop detail to DND.DROP_NONE because the
command
> cannot be executed or is null. Two, the drop listener returns false in
> isEnabled(..)

So I have to subclass which class?

Re: Drag and Drop creation [message #60260 is a reply to message #60236]

Thu, 30 January 2003 14:53

Eclipse User

Originally posted by: none.us.ibm.com

"Gunnar Wagenknecht" <g.wagenknecht@planet-wagenknecht.de> wrote in message
news:b1btc7$ai7$1@rogue.oti.com...
>
> "Randy Hudson" <none@us.ibm.com> schrieb im Newsbeitrag
> news:b16vvm$lu2$1@rogue.oti.com...
> > This is an interesting question. You are right that it is inconsistent.
> > What you want is a NOT cursor. There are two ways to do this. One, the
> > drop listener is still active because there is a target editpart, and
> > handleDragOver changes the Drop detail to DND.DROP_NONE because the
> command
> > cannot be executed or is null. Two, the drop listener returns false in
> > isEnabled(..)
>
> So I have to subclass which class?

TemplateDropTargetListener, probably.

Previous Topic:	How can install the example project of GEF?
Next Topic:	GEF plugin is disabled

Goto Forum:

-=] Back to Top [=-

Current Time: Tue May 13 06:22:04 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter