Double wxEVT_LEFT_UP events for clicks on native controls in wxOSX

[vadz]

There is some code in src/osx/cocoa/window.mm which synthesizes artificial wxEVT_LEFT_UP events when clicking on standard controls. This is clearly done on purpose and was added by r69886 but I have no idea why is it necessary and removing it does not result in #12363 reappearing, at least not with the stuff tested in the scroll sample under 10.8. OTOH removing it does fix the duplicate events as can be tested with the following change in the sample:

samples/minimal/minimal.cpp

@@ -141 +141 @@
 // main frame
 // ----------------------------------------------------------------------------
 
+static wxListBox* g_lbox;
+
+static void OnLabelClick(wxMouseEvent& event)
+{
+    event.Skip();
+
+    g_lbox->Append(wxString::Format("Clicked at %s",
+                                    wxDateTime::Now().Format("%H:%M:%S.%l")));
+}
+
 // frame constructor
 MyFrame::MyFrame(const wxString& title)
        : wxFrame(NULL, wxID_ANY, title)
@@ -167 +177 @@
     SetMenuBar(menuBar);
 #endif // wxUSE_MENUS
 
+    wxStaticText* st = new wxStaticText(this, wxID_ANY, "Click me", wxPoint(5, 5));
+    g_lbox = new wxListBox(this, wxID_ANY, wxPoint(5, 30), wxSize(200, 200));
+    st->Bind(wxEVT_LEFT_UP, OnLabelClick);
+
 #if wxUSE_STATUSBAR
     // create a status bar just for fun (by default with 1 pane only)
     CreateStatusBar(2);

With current svn you get 2 lines for each click (under both 10.7 and 10.8 but I didn't test other versions). With

src/osx/cocoa/window.mm

@@ -1147 +1147 @@
         {
             wxOSX_EventHandlerPtr superimpl = (wxOSX_EventHandlerPtr) [[slf superclass] instanceMethodForSelector:(SEL)_cmd];
             superimpl(slf, (SEL)_cmd, event);
-
-            // super of built-ins keeps the mouse up, as wx expects this event, we have to synthesize it
-
-            if ( [ event type]  == NSLeftMouseDown )
-            {
-                wxMouseEvent wxevent(wxEVT_LEFT_DOWN);
-                SetupMouseEvent(wxevent , event) ;
-                wxevent.SetEventType(wxEVT_LEFT_UP);
-
-                GetWXPeer()->HandleWindowEvent(wxevent);
-            }
         }
     }
 }

you only get one, as expected.

So why do we do this and what's going to happen if we don't?

[csomor]

That must have been a different bug id for the missing mouse up event. The problem was that a native mouse tracking code of controls was running and only quit upon releasing the mouse, thus eating the 'mouse-up'. It may very well be that this is handled differently in different version, I'll try to find the original bug report.

[csomor]

ok, it was my own code that showed that problem: the LEFT_UP is swallowed for native controls like buttons, ONLY für static controls, that don't to any tracking, it is still sent natively, resulting in a double delivery.

[SC]

(In [73189]) avoid double up events for static text, fixes #14902

[robind]

This change causes a compilation error on a 10.6 system:

/work/projects/buildbots/osx_10.6-py27/build-osx-py32/wxWidgets/src/osx/cocoa/window.mm: In member function ‘virtual void wxWidgetCocoaImpl::mouseEvent(NSEvent*, NSView*, void*)’:
/work/projects/buildbots/osx_10.6-py27/build-osx-py32/wxWidgets/src/osx/cocoa/window.mm:1153: warning: ‘NSEvent’ may not respond to ‘+pressedMouseButtons’
/work/projects/buildbots/osx_10.6-py27/build-osx-py32/wxWidgets/src/osx/cocoa/window.mm:1153: warning: (Messages without a matching method signature
/work/projects/buildbots/osx_10.6-py27/build-osx-py32/wxWidgets/src/osx/cocoa/window.mm:1153: warning: will be assumed to return ‘id’ and accept
/work/projects/buildbots/osx_10.6-py27/build-osx-py32/wxWidgets/src/osx/cocoa/window.mm:1153: warning: ‘...’ as arguments.)
/work/projects/buildbots/osx_10.6-py27/build-osx-py32/wxWidgets/src/osx/cocoa/window.mm:1153: error: invalid operands of types ‘objc_object*’ and ‘int’ to binary ‘operator&’

[csomor]

this exists in 10.6 SDK, are you building against an earlier SDK ?

[SC]

(In [73192]) support SDK < 10.6, fixes #14902

[robind]

Replying to csomor:

this exists in 10.6 SDK, are you building against an earlier SDK ?

Yes, it looks like they are using the 10.5 SDK.

Thanks.