Opened 11 years ago

Closed 3 years ago

#3821 closed defect (fixed)

wxComboBox doesn't process correctly TAB or SHIFT+TAB

Reported by: climentml Owned by: csomor
Priority: normal Milestone:
Component: wxOSX Version:
Keywords: wxComboBox key navigate Cc: climentml, csomor
Blocked By: #15003, #15003, #15003, #15003, #15003, #15003 Blocking:
Patch: no



wxMac 2.8.0 stable, Mac OS X 10.4.8 Tiger, XCode 2.4, GCC 4.0.1

Multiple controls on a wxDialog, one of them is a wxComboBox. Tab navigation works fine when only TAB key is pressed, but when trying navigating backwards using SHIFT+TAB, the navigation works okay only till reaching the wxComboBox. From there, it will loop between wxComboBox and the next (in the TAB order) control (set with MoveAfterInTabOrder in my case).
The problem can also be reproduced using the 'controls' sample found in the samples directory, when selecting the 'wxComboBox' tab.

Changing in wxComboBox::OnChar implementation (wxMac-2.8.0/src/mac/carbon/combobox.cpp)




fixed the problem for me.

Attachments (1)

combobox.patch download (508 bytes) - added by climentml 11 years ago.
Patch for the wxMac's wxCombBox.cpp shift+tab problem

Download all attachments as: .zip

Change History (15)

Changed 11 years ago by climentml

Patch for the wxMac's wxCombBox.cpp shift+tab problem

comment:1 Changed 11 years ago by climentml

Patch is attached.

File Added: combobox.patch

comment:2 Changed 10 years ago by wxsite

  • Status changed from assigned to confirmed

transitioning old 'assigned' status to new 'confirmed' status

comment:3 Changed 5 years ago by oneeyeman

This is still reproducible with the current trunk 10.6 Cocoa build.

comment:4 Changed 5 years ago by vadz

  • Component changed from wxOSX-Carbon to wxOSX-Cocoa

Pity that the patch checkbox hasn't been checked, as the patch for Carbon does look correct to me and I'll apply it. I don't know what to do about Cocoa (where the bug does indeed still happen), there is nothing special in wxComboBox code there so I have no idea why doesn't it work for it.

comment:5 Changed 5 years ago by VZ

(In [73054]) Handle Shift-TAB correctly in wxOSX/Carbon wxComboBox.

The navigation event direction should depend on Shift key state.

See #3821.

comment:6 Changed 5 years ago by johnr

  • Blocked By 15003 added
  • Keywords wxComboBox key navigate added
  • Summary changed from wxComboBox doesn't process correctly SHIFT+TAB to wxComboBox doesn't process correctly TAB or SHIFT+TAB

This doesn't work properly in cocoa with either TAB or Shift-TAB because of the absence of wxComboBox OnChar event generation and a routine such as is used in textctrl_osx.cpp wxTextCtrl::OnChar(). In a simple layout the default navigation is often correct but in a more complex layout with columns and several combos together navigation does not follow wxWidgets' tab order or object creation order.

A fix needs #15003 fixed first to conform with wxTextCtrl's approach.

In cocoa there other controls where this happens eg wxSpinCtrl buttons, wxButtons and likely any control without dedicated key navigation control. I thought the parent window/panel could get the key events if not handled by its children and do navigation from there and maybe it does somewhere in there but I haven't found it.

comment:7 Changed 5 years ago by SC

  • Blocked By

(In #15003) (In [73961]) applying editor part of patch, see #15003

comment:8 Changed 5 years ago by csomor

  • Blocked By

(In #15003) Thanks a lot for your patch John, adding the editor is the right thing to do IMHO.

What I don't see is the reason you've changed the filterSendEvent - you're now using the return value of the HandleMouseEvent of the captured window for 'handled' - do you have a bug that was related to the former way of never dealing with the mouse event in another window if there's a captured window.

comment:9 Changed 5 years ago by johnr

  • Blocked By

(In #15003) Ah yes, it is not proper nor needed. I had almost forgotten about the patch let alone the changes to filterSendEvent :) i.e.

handled = ((wxWidgetCocoaImpl*)cw->GetPeer())->DoHandleMouseEvent( event); 
//handled = true; 

The above code doesn't exist in my working copy anymore and was used originally as a rough workaround for a problem using wxRichTextToolTip over controls that need to receive mouse events and so made it into this patch. Sorry for not noticing and thanks for weeding it out.

I did initially think more work might be needed for combo events but it works well for me. A couple of keys do not produce a keydown event but do produce a keyup event. From memory, I think the Enter key is the main protagonist and maybe adding wxTE_PROCESS_ENTER to the user's constructor might help but I didn't try it.

comment:10 Changed 5 years ago by csomor

  • Blocked By

(In #15003) I don't see any problems anymore, all keystrokes (including ENTER) seem to be logged correctly, so I'm closing this

comment:11 Changed 5 years ago by johnr

  • Blocked By

(In #15003) Replying to csomor:

I don't see any problems anymore, all keystrokes (including ENTER) seem to be logged correctly

From memory the drop down list, when open, swallowed the ENTER key down stroke to close the list but understandably not the key up component. I am not sure how this compares to the MSW version.

comment:12 Changed 4 years ago by oneeyeman

Apparently wxComboBox::OnChar() is not enough.
I just tried to put such function and the keyDown override in the and still didn't get any TAB response.
Looking under gdb I see that the flow does not even ends up in keyDown override.

What am I missing?
I can upload the patch I used for testing...

comment:13 Changed 3 years ago by oneeyeman

I think that since 9862 (and 14269) are good this ticket also should be closed.

comment:14 Changed 3 years ago by disc

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

(Shift-)tabbing over a wxComboBox works correctly in wxOSX/Cocoa (3.0.0, ~3.0.3, and ~3.1.0).

Note: See TracTickets for help on using tickets.