wxComboBox doesn't process correctly TAB or SHIFT+TAB

[climentml]

Context:

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)

NavEvent.SetDirection(true);

with

NavEvent.SetDirection(!event.ShiftDown());

fixed the problem for me.

[climentml]

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

[climentml]

Patch is attached.

File Added: combobox.patch

[wxsite]

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

[oneeyeman]

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

[vadz]

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.

[VZ]

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

The navigation event direction should depend on Shift key state.

See #3821.

[johnr]

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.

[SC]

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

[csomor]

(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.

[johnr]

(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.