Home » Eclipse Projects » GEF » DND issue
| DND issue [message #77060] |
Mon, 28 April 2003 11:28  |
Eclipse User |
|
|
|
Originally posted by: melaasar.rational.com
Hello,
I think I found a problem with GEF's DelegatingDropAdapter. The dragLeave()
function is called in SWT in three cases:
1) When the cursor has left the drop target boundaries
2) When the drop is cancelled
3) When the data is about to be dropped
For the first two cases, the implementation of dragLeave() in the
DelegatingDropAdapter is fine (by setting the current listener to null after
calling the listener's dragLeave() method). However, for the third case, the
current listener is unfairly reset. This results in two consequences when
the drop() event is later called:
1) The event detail is reverted back to the original detail (captured in
dragEnter()) in isEnabled() method and never put back to the listener's
modified one since the current listener now is "null". and
updateCurrentListener() kind of only sets it back if the listener "has not"
changed. To overcome this, a listener needs to put back his desired detail
in "handeDrop()" (which is not documented), otherwise he will be left with
the system default, which is DROP_MOVE for windows resulting in potentially
undesired effect.
2) The listner's dragEnter() is called again from setCurrentListener() as it
thinks this is a first time listener match, which is kind of confusing and
could lead to potential problems if you override drag enter to do
initialization stuff. Atleast, there should be some documentation to
discourage that.
Let me know what you think...
Maged
|
|
|
| Re: DND issue [message #77068 is a reply to message #77060] |
Mon, 28 April 2003 11:34  |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
Do you have any suggestions as to how to fix this? When we receive the
"drag leave" event, there is no possible way to distinguish between #2 and
#3.
If you change the detail, you probably do this in dragEnter(). So the fact
that we call dragEnter twice might be helpful, no? Do you think we just
need more documentation?
"Maged Elaasar" <melaasar@rational.com> wrote in message
news:b8jh56$39t$1@rogue.oti.com...
> Hello,
>
> I think I found a problem with GEF's DelegatingDropAdapter. The
dragLeave()
> function is called in SWT in three cases:
>
> 1) When the cursor has left the drop target boundaries
> 2) When the drop is cancelled
> 3) When the data is about to be dropped
>
> For the first two cases, the implementation of dragLeave() in the
> DelegatingDropAdapter is fine (by setting the current listener to null
after
> calling the listener's dragLeave() method). However, for the third case,
the
> current listener is unfairly reset. This results in two consequences when
> the drop() event is later called:
>
> 1) The event detail is reverted back to the original detail (captured in
> dragEnter()) in isEnabled() method and never put back to the listener's
> modified one since the current listener now is "null". and
> updateCurrentListener() kind of only sets it back if the listener "has
not"
> changed. To overcome this, a listener needs to put back his desired detail
> in "handeDrop()" (which is not documented), otherwise he will be left with
> the system default, which is DROP_MOVE for windows resulting in
potentially
> undesired effect.
>
> 2) The listner's dragEnter() is called again from setCurrentListener() as
it
> thinks this is a first time listener match, which is kind of confusing and
> could lead to potential problems if you override drag enter to do
> initialization stuff. Atleast, there should be some documentation to
> discourage that.
>
> Let me know what you think...
>
> Maged
>
>
|
|
|
| Re: DND issue [message #77082 is a reply to message #77068] |
Mon, 28 April 2003 12:26 |
| Eclipse User |
|
|
|
Originally posted by: melaasar.rational.com
I think it should be addressed in a combination of fix/documentation like
this:
In AbstractTransferDropTargetListener.class:
public void dragEnter(DropTargetEvent event) {
if (GEF.DebugDND)
GEF.debug("Drag Enter: " + toString()); //$NON-NLS-1$
resetHover();
setCurrentEvent(event);
handleDragEnter();
}
/**
* Called whenever the User enters the target. By default, the target Request
and
* target EditPart are updated, and feedback is.
* This method could be called several times in a single DND scenario,
therefore
* avoid doing any initializations that need to be done once here
*/
protected void handleDragEnter() {
handleDragOver(); // or copying similar code here
}
This will make sure that drag enter is called and the event detail is
properly set the second time. It can also help
the first time it is called, since dragOver does not have to assume the
responsibility for setting the initial detail.
Maged
"Randy Hudson" <none@us.ibm.com> wrote in message
news:b8jhmm$3sl$1@rogue.oti.com...
> Do you have any suggestions as to how to fix this? When we receive the
> "drag leave" event, there is no possible way to distinguish between #2 and
> #3.
>
> If you change the detail, you probably do this in dragEnter(). So the
fact
> that we call dragEnter twice might be helpful, no? Do you think we just
> need more documentation?
>
> "Maged Elaasar" <melaasar@rational.com> wrote in message
> news:b8jh56$39t$1@rogue.oti.com...
> > Hello,
> >
> > I think I found a problem with GEF's DelegatingDropAdapter. The
> dragLeave()
> > function is called in SWT in three cases:
> >
> > 1) When the cursor has left the drop target boundaries
> > 2) When the drop is cancelled
> > 3) When the data is about to be dropped
> >
> > For the first two cases, the implementation of dragLeave() in the
> > DelegatingDropAdapter is fine (by setting the current listener to null
> after
> > calling the listener's dragLeave() method). However, for the third case,
> the
> > current listener is unfairly reset. This results in two consequences
when
> > the drop() event is later called:
> >
> > 1) The event detail is reverted back to the original detail (captured in
> > dragEnter()) in isEnabled() method and never put back to the listener's
> > modified one since the current listener now is "null". and
> > updateCurrentListener() kind of only sets it back if the listener "has
> not"
> > changed. To overcome this, a listener needs to put back his desired
detail
> > in "handeDrop()" (which is not documented), otherwise he will be left
with
> > the system default, which is DROP_MOVE for windows resulting in
> potentially
> > undesired effect.
> >
> > 2) The listner's dragEnter() is called again from setCurrentListener()
as
> it
> > thinks this is a first time listener match, which is kind of confusing
and
> > could lead to potential problems if you override drag enter to do
> > initialization stuff. Atleast, there should be some documentation to
> > discourage that.
> >
> > Let me know what you think...
> >
> > Maged
> >
> >
>
>
|
|
|
| Re: DND issue [message #77099 is a reply to message #77082] |
Mon, 28 April 2003 12:57 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
DropTargetListener.dragEnter() may be called multiple times in SWT too
(mouse leaves and returns to the drop target). This is not specific to GEF.
The only thing strange is that dropAccept may come before a dragEnter().
And DOC updates would be added to TransferDropTargetListener. BTW, JFace
has taken over ownership of these implementations. I'm not sure how GEF
will move to the new implementation. Perhaps just extend them, and deprecate
our java types.
"Maged Elaasar" <melaasar@rational.com> wrote in message
news:b8jkhu$738$1@rogue.oti.com...
> I think it should be addressed in a combination of fix/documentation like
> this:
>
> In AbstractTransferDropTargetListener.class:
>
> public void dragEnter(DropTargetEvent event) {
>
> if (GEF.DebugDND)
>
> GEF.debug("Drag Enter: " + toString()); //$NON-NLS-1$
>
> resetHover();
>
> setCurrentEvent(event);
>
> handleDragEnter();
>
> }
>
> /**
>
> * Called whenever the User enters the target. By default, the target
Request
> and
>
> * target EditPart are updated, and feedback is.
>
> * This method could be called several times in a single DND scenario,
> therefore
>
> * avoid doing any initializations that need to be done once here
>
> */
>
> protected void handleDragEnter() {
>
> handleDragOver(); // or copying similar code here
>
> }
>
> This will make sure that drag enter is called and the event detail is
> properly set the second time. It can also help
> the first time it is called, since dragOver does not have to assume the
> responsibility for setting the initial detail.
>
> Maged
>
> "Randy Hudson" <none@us.ibm.com> wrote in message
> news:b8jhmm$3sl$1@rogue.oti.com...
> > Do you have any suggestions as to how to fix this? When we receive the
> > "drag leave" event, there is no possible way to distinguish between #2
and
> > #3.
> >
> > If you change the detail, you probably do this in dragEnter(). So the
> fact
> > that we call dragEnter twice might be helpful, no? Do you think we just
> > need more documentation?
> >
> > "Maged Elaasar" <melaasar@rational.com> wrote in message
> > news:b8jh56$39t$1@rogue.oti.com...
> > > Hello,
> > >
> > > I think I found a problem with GEF's DelegatingDropAdapter. The
> > dragLeave()
> > > function is called in SWT in three cases:
> > >
> > > 1) When the cursor has left the drop target boundaries
> > > 2) When the drop is cancelled
> > > 3) When the data is about to be dropped
> > >
> > > For the first two cases, the implementation of dragLeave() in the
> > > DelegatingDropAdapter is fine (by setting the current listener to null
> > after
> > > calling the listener's dragLeave() method). However, for the third
case,
> > the
> > > current listener is unfairly reset. This results in two consequences
> when
> > > the drop() event is later called:
> > >
> > > 1) The event detail is reverted back to the original detail (captured
in
> > > dragEnter()) in isEnabled() method and never put back to the
listener's
> > > modified one since the current listener now is "null". and
> > > updateCurrentListener() kind of only sets it back if the listener "has
> > not"
> > > changed. To overcome this, a listener needs to put back his desired
> detail
> > > in "handeDrop()" (which is not documented), otherwise he will be left
> with
> > > the system default, which is DROP_MOVE for windows resulting in
> > potentially
> > > undesired effect.
> > >
> > > 2) The listner's dragEnter() is called again from setCurrentListener()
> as
> > it
> > > thinks this is a first time listener match, which is kind of confusing
> and
> > > could lead to potential problems if you override drag enter to do
> > > initialization stuff. Atleast, there should be some documentation to
> > > discourage that.
> > >
> > > Let me know what you think...
> > >
> > > Maged
> > >
> > >
> >
> >
>
>
|
|
|
Goto Forum:
Current Time: Tue Jul 15 16:20:28 EDT 2025
Powered by FUDForum. Page generated in 0.08124 seconds |
Home