Community
Participate
Working Groups
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.
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.
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.
(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.
Created attachment 185468 [details] Fix This patch will work on 10.5 and 10.6. It simplifies findControl a lot as well.
Fixed > 20101217.
