wxOSX/Carbon SetCursor patching

[wxtrac]

Issue migrated from trac ticket # 11519

component: wxOSX | priority: normal | resolution: outdated

2009-12-06 03:31:43: jatupper (Jeff Tupper) created the issue

---

Here is a patch that improves wxOSX/Carbon's handling of custom cursors. Some comments regarding the patch follow.

---

wxWindowMac::MacSetupCursor: I've removed

if ( !wxIsBusy() && GetParent() )
                cursor = *wxSTANDARD_CURSOR ;

as this end-of-loop case (of the child-to-parent looping) is now in the looping procedure itself (wxMacUpdateCursor).

---

wxMacControl::SetCursor: the current version (from trunk) compares mouseWin with tlwwx; older versions compared mouseWin with the pre-peer of *this. With my application, the current logic prevents SetCursor from installing cursors. (When I try setting the cursor in my wxWindow-derived object, wxMacControl::SetCursor ends up comparing that object (mouseWin) with its enclosing wxFrame (tlwwx) and then doesn't install the cursor.)

---

src/osx/carbon/nonownedwnd.cpp: what is the point of the following snippet? The patch brackets it out. (No loss of capture message is sent; the docs don't mention mouse-up as leading to an implicit loss of capture.)

         if ( cEvent.GetKind() == kEventMouseUp && wxApp::s_captureWindow )
         {
             wxApp::s_captureWindow = NULL ;
             // update cursor ?
          }

---

I guess that's about it. If there are specific questions, I can try to answer them. Custom cursor handling doesn't seem to be covered (much?) in the samples. My applications work better post-patch.

[wxtrac]

2009-12-06 03:32:06: jatupper (Jeff Tupper) uploaded file CarbonSetCursor.patch (7.7 KiB)

[wxtrac]

2009-12-06 11:01:37: jatupper (Jeff Tupper) uploaded file CarbonSetCursor2.patch (9.1 KiB)

[wxtrac]

2009-12-06 11:10:27: jatupper (Jeff Tupper) commented

---

The difference between the first and second patches is in wxWindowMac::MacSetupCursor.

Before the second patch (i.e. before patch 1 or with patch 1):

• Even if HasCapture() is true, a wxSetCursorEvent is sent and looked at

After the second patch:

• If HasCapture() is true, m_cursor is simply used; no wxSetCursorEvent is generated / sent / etc...

---

Before the second patch: during wxSplitterWindow sash dragging, the custom cursor (the sash resizing cursor) can be lost when the drag leaves the range of the wxSplitterWindow.

After the second patch: the custom cursor (the sash resizing cursor) is kept while the button remains down (even if the cursor leaves the wxSplitterWindow).

---

If the first patch is applied I can re-diff and submit a new patch against the new trunk.

[wxtrac]

2009-12-06 11:21:06: jatupper (Jeff Tupper) changed status from new to closed

2009-12-06 11:21:06: jatupper (Jeff Tupper) set resolution to fixed

2009-12-06 11:21:06: jatupper (Jeff Tupper) commented

Part of my reasoning behind the change from patch 1 to patch 2 was the following in the docs: "A wxSetCursorEvent is generated from wxWindow when the mouse cursor is about to be set as a result of mouse motion." This seems to weakly imply that wxSetCursorEvent isn't used when the mouse is captured. (Which also seems to be what wxSplitterWindow assumes. And, as an aside: the comment "// this is currently called (and needed) under MSW only..." in src/generic/splitter.cpp doesn't seem to be spot-on as wxSplitterWindow::OnSetCursor() is called on wxOSX.)

Should the wxSetCursorEvent docs be updated to clarify the event's relationship to captured mice?

[wxtrac]

2009-12-07 22:05:15: jatupper (Jeff Tupper) changed status from closed to reopened

2009-12-07 22:05:15: jatupper (Jeff Tupper) changed resolution from fixed to **

[wxtrac]

2009-12-07 22:14:43: jatupper (Jeff Tupper) commented

---

Obviously, I didn't mean to change the status to "closed". This sort of thing would happen less often if the Action wouldn't default to "close/resolve ticket". (Why trac does that I don't know... but I seem to have trouble remembering every time to make sure it doesn't implicitly close the ticket as having Action default to "close/resolve ticket" makes no sense to me.)

[wxtrac]

2018-03-04 08:03:53: @oneeyeman1 changed status from reopened to infoneeded_new

2018-03-04 08:03:53: @oneeyeman1 commented

jatupper, Does those changes still make sense for Cocoa?

[wxtrac]

2018-03-06 03:50:35: @oneeyeman1 changed status from infoneeded_new to new

2018-03-06 03:50:35: @oneeyeman1 changed component from old wxOSX/Carbon port to wxOSX

[wxtrac]

2018-03-06 03:51:12: @oneeyeman1 changed status from new to infoneeded_new

[wxtrac]

2019-08-12 16:54:05: @oneeyeman1 changed status from infoneeded_new to closed

2019-08-12 16:54:05: @oneeyeman1 set resolution to outdated

2019-08-12 16:54:05: @oneeyeman1 commented

Carbon version is not supported anymore - all development of wxWidgets is moved to Cocoa.

Since there is no response to comment #5, I'm closing the ticket.

Please re-open if there is any issues that can be improved with the current Cocoa implementation.