Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 332647

Summary: On Cocoa Hit test fails for shells with regions
Product: [Eclipse Project] Platform Reporter: Bogdan Gheorghe <gheorghe>
Component: SWTAssignee: Scott Kovatch <skovatch>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3    
Version: 3.7   
Target Milestone: 3.7 M5   
Hardware: PC   
OS: Mac OS X - Carbon (unsup.)   
Whiteboard:
Attachments:
Description Flags
Fix none

Description Bogdan Gheorghe CLA 2010-12-15 10:51:45 EST 
If you run Snippet 134 you get a shell with a keyhole region in the middle of it. If you position the shell over an Eclipse editor and put your mouse over the hole in the shell, the cursor should detect that you are over an editor and switch to the insertion cursor. This is the behaviour on Windows and Linux - on Cocoa you have to click 2 times to get it to switch to an insertion cursor.

It looks like we're doing a hit test on the wrong control. This is needed for e4 DND functionality.
Comment 1 Scott Kovatch CLA 2010-12-15 13:43:48 EST 
The cursor isn't changing because Eclipse isn't the active application. The reason you need to click is because that brings Eclipse to the foreground, and then Eclipse takes control of setting the cursor. Cursor management is only supposed to be done by the active window of the active application.

It looks like the expected behavior on Windows is to do cursor updates even when the window the cursor is over does not belong to an active application. That's not the normal behavior on Mac OS X.

I do see a bug in that if Eclipse _is_ active, and you place the round window over an editor the cursor doesn't switch back to the arrow when it is over the red portion of the shell, but I don't think that's what you are describing here.
Comment 2 Bogdan Gheorghe CLA 2010-12-17 10:00:11 EST 
Actually, that's the case that I *am* describing. ;)

This came up because Eric is trying to do some fancy DND stuff in e4. He needed a way to get the control under cursor while dragging a shell (calling getCursorControl would return the shell he's moving, not the control under the shell). So he created a small region in the shell he's dragging so he could call getCursorControl - works on Windows and GTK but not Cocoa.
Comment 3 Scott Kovatch CLA 2010-12-17 11:59:59 EST 
(In reply to comment #2)
> Actually, that's the case that I *am* describing. ;)
> 
> This came up because Eric is trying to do some fancy DND stuff in e4. He needed
> a way to get the control under cursor while dragging a shell (calling
> getCursorControl would return the shell he's moving, not the control under the
> shell). So he created a small region in the shell he's dragging so he could
> call getCursorControl - works on Windows and GTK but not Cocoa.

As long as the scenario you describe has the two shells in the same process I can fix this pretty easily on 10.6. Let me put a patch together for you to make sure it's what you want and then I'll figure out what to do on 10.5, since it will be a bit harder there.
Comment 4 Scott Kovatch CLA 2010-12-17 19:12:14 EST 
Created attachment 185468 [details]
Fix

This patch will work on 10.5 and 10.6. It simplifies findControl a lot as well.
Comment 5 Scott Kovatch CLA 2010-12-17 19:27:18 EST 
Fixed > 20101217.