This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 21757 - During one Drag operation are used diff instances of DragSourceContext.
Summary: During one Drag operation are used diff instances of DragSourceContext.
Status: VERIFIED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: PC Linux
: P1 blocker (vote)
Assignee: Peter Zavadsky
URL:
Keywords:
Depends on:
Blocks: 21610
  Show dependency tree
 
Reported: 2002-03-20 17:19 UTC by Peter Zavadsky
Modified: 2008-12-23 09:37 UTC (History)
0 users

See Also:
Issue Type: TASK
Exception Reporter:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Zavadsky 2002-03-20 17:19:55 UTC 
There are used during one Drag operation diff instances of DragSourceContext.
I guess that's wrong state. There should be only one instance. 
The current
state brakes the possibility to manage cursor setting based on previous cursor
type. Seems that events coming to dragEnter, dragExit have diff
DragSourceContext than the one in dragActionChanged on DragSourceListener.

It also creates memory leak having more than one instance and also possible
incositences of drag source states (beside cursor).
Comment 1 Peter Zavadsky 2002-03-21 09:12:59 UTC 
Fortunatelly it was my fault. Fixed on [winsys_dnd_2002Feb] branch.

I keep the dragsource context via weak reference (to be able used them
in dragEnterHack and dragExitHack methods, since the dragEnter
and dragEcit methods work not correclty in MDI, will fire a bug about
it). 
There happens sometimes between the two drag operations wasn't the
drag source context instance succesfully garbaged yet, thus the weak
ref pointed to the old instance. 
The fix just removes the weak ref after finish of the DnD.
Comment 2 Marian Mirilovic 2004-03-01 08:55:22 UTC 
issue doesn't apply to new window system - verified