Community
Participate
Working Groups
Raised bug to keep track of the Cocoa-specific misbehavior reported in bug #332809
Found out that the issue is caused by an inconsistent handling of a Tree's client area on MacOSX Cocoa (as reported by bug #333375). As the client area's y coordinate changes during scrolling on MacOSX Cocoa (in difference to Windows), the detection of a target edit part via TreeViewer#findObjectAtExcluding fails (there is a check, whether the searched location is inside the client area; null is returned if this is not the case).
Alexander, any chance for this to be fixed in 3.6?
(In reply to comment #2) > Alexander, any chance for this to be fixed in 3.6? Well, that's not really in my hands, as the underlying problem is an SWT issue alone. I think you would have to raise this question in bug #333375 though. The fix that has been applied there has - up to now - only be included in the 3.7 HEAD (while I could not verify that this is resolved because of "broken" Eclipse nightly builds in the last days). Maybe Scott would be willing to back-port it to 3.6.1 if you ask. If this is not going to happen, you might try to work around it in GEF by removing the check for client area containment within TreeViewer:findObjectAtEcluding: if (pt.x < 0 || pt.y < 0 || pt.x >= area.width || pt.y >= area.height) return null; I observed that this resolved the problem, but - even while I do not understand what this check has been added for - I think there must have been some motivation and I am thus not aware about any potential side-effects.
Changed client area check within TreeViewer to take into account that client area may not be fixed to (0,0) on all platforms, but may change during scrolling. The check is now: if (pt.x < area.x || pt.y < area.y || pt.x >= area.x + area.width || pt.y >= area.y + area.height) return null; Committed changes to cvs HEAD as well as 3_6_maintenance branch. Verified that DnD now also works on Cocoa when scrolling is involved.
