Ctrl-(Shift-)Tab doesn't properly navigate over tabs on OSX (wxwidgets3.1)

[paulc...@gmail.com]

Hi All,

I'm having this strange issue with tab navigation on OSX and hope someone can shed some light on how it's supposed to work.

I have wxAuiNotebook and when I use Ctrl-Tab and Ctrl-Shift-Tab, everything work until I get to the first or the last tab. After that the control jumps to some other (seemingly arbitrary) component on the same frame (it may be a tab in a different wxAuiNotebook or a different control). It happens absolutely consistently, which produces very strange and inconvenient effect as it completely breaks the navigation. I tested on Windows and the behavior is absolutely correct there (with tab navigation wrapping around the tabs in the same notebook).

What's even stranger is that I can attach wxEVT_NAVIGATION_KEY event to the notebook and I can get to see (and cancel if I want to) these events on Windows; the same event is not triggered on OSX. Obviously, my controls don't get to see the TAB key when it's pressed, so I can't do anything to overwrite this behavior.

I did find an early post from Vadim on this topic (https://groups.google.com/d/msg/wx-users/0iz_DZiZd0c/5dfiRAKTJYEJ), but he simply stated there that Ctrl-Tab should work in this case.

I tested this behavior on 2.9.5 and on 3.1 (from couple of weeks ago) and it doesn't work in exactly the same way on OSX. I tried with the aui sample and while it does show the same strange behavior (on OSX). I vaguely remember that I might have already commented on this in one of the tickets, but with trac being down for upgrade I can't check.

I can try to debug it further, but what part of the code handles this logic? It seems like it's handled somewhere in wxWindowBase::DoMoveInTabOrder and wxWindowBase::HandleAsNavigationKey, but I'm not certain.

Is there a way to intercept this event and provide my own tab navigation? I tried attaching EVT_NAVIGATION_KEY to the notebook and to the frame itself, I tried catching TAB key and few other desperate attempts, but so far nothing has worked.

Paul.

[paulc...@gmail.com]

> Is there a way to intercept this event and provide my own tab navigation? I tried attaching EVT_NAVIGATION_KEY to the notebook and to the frame itself, I tried catching TAB key and few other desperate attempts, but so far nothing has worked.

What's even worse is that I can overwrite the default Ctrl-Tab behavior on Windows by assigning a menu shortcut, but this doesn't work on OSX.

Vadim, is there any way to change this behavior on OSX? I'll settle for a workaround. If you agree that it's not the expected behavior, I can open a ticket. Thank you.

Paul.

[Vadim Zeitlin]

On Wed, 2 Apr 2014 09:32:26 -0700 (PDT) wrote:

> > Is there a way to intercept this event and provide my own tab navigation?
> I tried attaching EVT_NAVIGATION_KEY to the notebook and to the frame
> itself, I tried catching TAB key and few other desperate attempts, but so
> far nothing has worked.
>
> What's even worse is that I can overwrite the default Ctrl-Tab behavior on
> Windows by assigning a menu shortcut, but this doesn't work on OSX.
>
> Vadim, is there any way to change this behavior on OSX?

Sorry, no idea. I don't even know if the native applications provide any
way to change the current page from keyboard.

Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
http://www.tt-solutions.com/

[Steve Barnes]

On 02/04/14 20:33, Vadim Zeitlin wrote:

On Wed, 2 Apr 2014 09:32:26 -0700 (PDT)  wrote:

Is there a way to intercept this event and provide my own tab navigation? 

I tried attaching EVT_NAVIGATION_KEY to the notebook and to the frame 
itself, I tried catching TAB key and few other desperate attempts, but so 
far nothing has worked.

What's even worse is that I can overwrite the default Ctrl-Tab behavior on 
Windows by assigning a menu shortcut, but this doesn't work on OSX.

Vadim, is there any way to change this behavior on OSX?

 Sorry, no idea. I don't even know if the native applications provide any
way to change the current page from keyboard.

 Regards,
VZ

Some possibilities if it helps:

⌘+Shift+[/⌘+Shift+]Jump to next / jump to previous tab

Chrome:

Press ⌘-Option and the right arrow together.	Switches to the next tab.
Press ⌘-Option and the left arrow together.	Switches to the previous tab.

[paulc...@gmail.com]

> Some possibilities if it helps:

⌘+Shift+[/⌘+Shift+]Jump to next / jump to previous tab

> Chrome:

Press ⌘-Option and the right arrow together.	Switches to the next tab.
Press ⌘-Option and the left arrow together.	Switches to the previous tab.

These are good suggestions, but most of my users expect Cmd-(Shift-)Tab to work ;).

So it seems like there are several issues on OSX: (1) Cmd-Tab doesn't properly work on and (2) there is no way to change that behavior and provide my own handler (this works on Windows). There is also (3) EVT_NAVIGATION_KEY doesn't fire when attached to a notebook (also works on Windows).

Vadim, should I open a ticket for each of these?

Paul.

[Stefan Csomor]

Hi

These are good suggestions, but most of my users expect Cmd-(Shift-)Tab to work ;).

Cmd-(Shift)-Tab on OSX is a system wide shortcut allowing users to switch forward and backward through their apps.

Best,

Stefan

[paulc...@gmail.com]

Hi Stefan,

> Cmd-(Shift)-Tab on OSX is a system wide shortcut allowing users to switch forward and backward through their apps.

You are of course correct; I meant Ctrl-(Shift)-Tab.

Any idea where the processing of these combinations could go wrong? I don't mind digging into the code, but I'm not familiar with the OSX-related parts.

Paul.

[John Roberts]

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to wx-users+u...@googlegroups.com
or visit http://groups.google.com/group/wx-users

Paul

Keyboard navigation in wxOsx-Cocoa is incomplete from a wxWidgets viewpoint and navigation is often handled by the native "super" side of the application. Some controls that can be tabbed into and get focus are impossible to tab away from e.g. spinctrl buttons. Place controls in a multi-column sizer and the tab order can be bizarre despite your tab order setting unless they are all textctrls .

Most controls derived from wxTextBoxes are generally ok because wxTextCtrl catches OnChar events and calls Navigate(). Some controls have partial key range support for OnChar but do not generate events for TAB, e.g. wxComboCtrl, and require OnKey (rather than OnChar) event handling  to trap the key presses. If the control doesn't respond to the selector then you don't get it.

I don't have an Apple box in front of me but from memory src/osx/cocoa window.mm and I think nonownedwnd.mm have the central key event handling routines. OnChar stuff worsened with a fairly recent revision: see 

<http://trac.wxwidgets.org/ticket/15903>

I am not sure whether the above is relevant but may fill in some gaps, John

[paulc...@gmail.com]

Hi John,

> I don't have an Apple box in front of me but from memory src/osx/cocoa window.mm and I think nonownedwnd.mm have the central key event handling routines. OnChar stuff worsened with a fairly recent revision: see 

<http://trac.wxwidgets.org/ticket/15903>

Thank you for the pointers. I did reviewed those files you referenced, but I still don't see where that Ctrl-TAB may be handled.

I was hoping that I could find a workaround by using EVT_CHAR_HOOK, but unfortunately TAB is not registered by that handler either (Ctrl does appear in the handler though), which makes it more than an inconvenience for me.

Here is the list of all the places that appear to handle WXK_TAB that may be relevant to this issue:

- src/aui/auibook.cpp: void wxAuiTabCtrl::OnChar(wxKeyEvent& event)

  this is what is expected to handle Ctrl-Tab. Not being hit on OSX

- src/common/wincmn.cpp: bool wxWindowBase::HandleAsNavigationKey(const wxKeyEvent& event)

  this is what is supposed to generate EVT_NAVIGATION_KEY. Not generated on OSX

- src/osx/carbon/app.cpp: bool wxApp::MacSendCharEvent( wxWindow* focus , long keymessage , long modifiers , long when , wxChar uniChar )

  has handling of WXK_TAB, but inside #if wxOSX_USE_CARBON and I'm using cocoa

The last fragment looks like the code that would jump between controls on Ctrl-Tab (which is what I see on OSX), but I don't understand why it would execute if it's behind wxOSX_USE_CARBON check.

I'll try to put some debugging there to figure out what may be going on, but any pointers on where to look for this Ctrl-Tab handling would be appreciated. Thank you.

Paul.