Opened 22 months ago

Closed 22 months ago

Last modified 22 months ago

#14902 closed defect (fixed)

Double wxEVT_LEFT_UP events for clicks on native controls in wxOSX

Reported by: vadz Owned by: csomor
Priority: normal Milestone: 2.9.5
Component: wxOSX-Cocoa Version: stable-latest
Keywords: events Cc:
Blocked By: Blocking:
Patch: no


There is some code in src/osx/cocoa/ 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

    diff --git a/samples/minimal/minimal.cpp b/samples/minimal/minimal.cpp
    index a78e462..5261d94 100644
    a b bool MyApp::OnInit() 
    141141// main frame 
    142142// ---------------------------------------------------------------------------- 
     144static wxListBox* g_lbox; 
     146static void OnLabelClick(wxMouseEvent& event) 
     148    event.Skip(); 
     150    g_lbox->Append(wxString::Format("Clicked at %s", 
     151                                    wxDateTime::Now().Format("%H:%M:%S.%l"))); 
    144154// frame constructor 
    145155MyFrame::MyFrame(const wxString& title) 
    146156       : wxFrame(NULL, wxID_ANY, title) 
    MyFrame::MyFrame(const wxString& title) 
    167177    SetMenuBar(menuBar); 
    168178#endif // wxUSE_MENUS 
     180    wxStaticText* st = new wxStaticText(this, wxID_ANY, "Click me", wxPoint(5, 5)); 
     181    g_lbox = new wxListBox(this, wxID_ANY, wxPoint(5, 30), wxSize(200, 200)); 
     182    st->Bind(wxEVT_LEFT_UP, OnLabelClick); 
    170184#if wxUSE_STATUSBAR 
    171185    // create a status bar just for fun (by default with 1 pane only) 
    172186    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/

    diff --git a/src/osx/cocoa/ b/src/osx/cocoa/
    index 166388b..7f9de34 100644
    a b void wxWidgetCocoaImpl::mouseEvent(WX_NSEvent event, WXWidget slf, void *_cmd) 
    11471147        { 
    11481148            wxOSX_EventHandlerPtr superimpl = (wxOSX_EventHandlerPtr) [[slf superclass] instanceMethodForSelector:(SEL)_cmd]; 
    11491149            superimpl(slf, (SEL)_cmd, event); 
    1151             // super of built-ins keeps the mouse up, as wx expects this event, we have to synthesize it 
    1153             if ( [ event type]  == NSLeftMouseDown ) 
    1154             { 
    1155                 wxMouseEvent wxevent(wxEVT_LEFT_DOWN); 
    1156                 SetupMouseEvent(wxevent , event) ; 
    1157                 wxevent.SetEventType(wxEVT_LEFT_UP); 
    1159                 GetWXPeer()->HandleWindowEvent(wxevent); 
    1160             } 
    11611150        } 
    11621151    } 

you only get one, as expected.

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

Change History (7)

comment:1 Changed 22 months ago by 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.

comment:2 Changed 22 months ago by csomor

  • Owner set to csomor
  • Status changed from new to accepted

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.

comment:3 Changed 22 months ago by SC

  • Resolution set to fixed
  • Status changed from accepted to closed

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

comment:4 Changed 22 months ago by robind

  • Resolution fixed deleted
  • Status changed from closed to reopened

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

comment:5 follow-up: Changed 22 months ago by csomor

  • Status changed from reopened to accepted

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

comment:6 Changed 22 months ago by SC

  • Resolution set to fixed
  • Status changed from accepted to closed

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

comment:7 in reply to: ↑ 5 Changed 22 months ago by 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.


Note: See TracTickets for help on using tickets.