Opened 19 months ago

Closed 19 months ago

Last modified 18 months ago

#15070 closed defect (fixed)

SetFocus fails on wxSTC control inside wxAuiNotebook (OSX)

Reported by: paulclinger Owned by: csomor
Priority: normal Milestone:
Component: wxOSX (any toolkit) Version: stable-latest
Keywords: Cc:
Blocked By: Blocking:
Patch: no

Description

When SetFocus is called on wxSTC control in one of the tabs in wxAuiNotebook, the control fails to receive the focus and ignores keyboard input until the editor area is clicked on. Adding SetSTCFocus doesn't help.

This is the discussion from the maillist: https://groups.google.com/d/topic/wx-users/CBC0XFXK6Og/discussion

Steps to reproduce. (1) Take the aui sample and add OnNotebookPageChanged linked to EVT_AUINOTEBOOK_PAGE_CHANGED event:

void MyFrame::OnNotebookPageChanged(wxAuiNotebookEvent& evt) {

wxAuiNotebook* ctrl = (wxAuiNotebook*)evt.GetEventObject();
wxWindow* trgt = ctrl->GetPage(ctrl->GetSelection());
trgt->SetFocus();
evt.Skip();

}

Now when the tab is clicked, the focus is on the wxTextCtrl in that tab and you can start typing text right away.

(2) Modify two of the tabs to use wxStyledTextCtrl instead of wxTextCtrl (for example, tabs 3 and 4). Now when *these* tabs are clicked, the focus is still on the tab itself (you can see this because arrow keys will move control between tabs) and the text cannot be typed into the editor control (you can click on the editor window, but I need to set the focus programmatically).

If SetSTCFocus call is added, then a blinking cursor can be seen in the editor, but the keyboard input is still not going there and the focus is still on the tab control as you can change tabs by using arrow keys.

if (ctrl->GetSelection() == 3) {

((wxStyledTextCtrl*)wxDynamicCast(trgt, wxStyledTextCtrl))->SetSTCFocus(true);

}

Using wxNotebook instead of wxAuiNotebook doesn't have this issue. Using wxTextCtrl instead of wxStyledTextCtrl doesn't have this issue. Using Windows instead of OSX doesn't have this issue.

Possibly relevant tickets that deal with focus changes: http://trac.wxwidgets.org/ticket/14938, http://trac.wxwidgets.org/ticket/14142, and http://trac.wxwidgets.org/ticket/13495.

Unfortunately I can't find a workaround to set focus, so it's a noticeable issue for my users.

(wxAuiNotebook, wxStyledTextCtrl, OSX cocoa compiled with 10.7)

Change History (9)

comment:1 Changed 19 months ago by csomor

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

comment:2 Changed 19 months ago by SC

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

(In [73610]) implementing canBecomeKeyView for user panes, native focus support, fixes #15070

comment:3 Changed 19 months ago by paulclinger

Confirmed fixed; thank you!

comment:4 Changed 19 months ago by johnr

  • Resolution fixed deleted
  • Status changed from closed to reopened

FYI the line below crashes when showing richtooltips.

src/osx/window_osx.cpp
WX_DECLARE_HASH_MAP(WXWidget, wxWidgetImpl*, wxPointerHash, wxPointerEqual, MacControlMap);

when called from

- (BOOL) canBecomeKeyView 
{ 
    wxWidgetCocoaImpl* viewimpl = (wxWidgetCocoaImpl* ) wxWidgetImpl::FindFromWXWidget( self );
    ... 

comment:5 Changed 19 months ago by paulclinger

Spoke too soon; the issue in the ticket is indeed fixed, but I also see crashes when auto-complete window is (about to be) displayed in wxSTC.

comment:6 Changed 19 months ago by csomor

  • Status changed from reopened to accepted

comment:7 Changed 19 months ago by paulclinger

If this is of any help, from the crash report it seems to be looping recursively (unfortunately I don't see exactly where even when compiled with debug info):

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libwx.dylib 0x012f6764 0x1000000 + 3106660
1 libwx.dylib 0x0124547d 0x1000000 + 2380925
2 libwx.dylib 0x012f7a50 0x1000000 + 3111504
3 libwx.dylib 0x012f678e 0x1000000 + 3106702
4 libwx.dylib 0x0124547d 0x1000000 + 2380925
5 libwx.dylib 0x012f7a50 0x1000000 + 3111504
6 libwx.dylib 0x012f678e 0x1000000 + 3106702
7 libwx.dylib 0x0124547d 0x1000000 + 2380925
8 libwx.dylib 0x012f7a50 0x1000000 + 3111504
9 libwx.dylib 0x012f678e 0x1000000 + 3106702
10 libwx.dylib 0x0124547d 0x1000000 + 2380925
11 libwx.dylib 0x012f7a50 0x1000000 + 3111504
12 libwx.dylib 0x012f678e 0x1000000 + 3106702
.... many more calls like this

comment:8 Changed 19 months ago by SC

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

(In [73614]) avoid infinite recursion for richtooltops, (hopefully) fixes #15070

comment:9 Changed 18 months ago by paulclinger

Stefan,

One question on this. I noticed that the editor tab gets activated on Linux and Windows even without explicit SetFocus call in EVT_AUINOTEBOOK_PAGE_CHANGED event, but on OSX this doesn't happen. An easy way to demonstrate: take AuiNotebook with several editor tabs (wxSTC will do). After clicking on a tab, the editor in the tab is editable in Windows and Linux, but not in OSX.

To summarize, before you fixed this issue, even explicit SetFocus didn't work on OSX with wxSTC controls; now there seems to be implicit SetFocus when a tab is clicked that works on Linux/Windows, but not OSX.

I'm "fixing" this by using PAGE_CHANGED event, but I thought it's strange that it doesn't work in OSX.

Also, tangentially related: wxEVT_SET_FOCUS attached to notebook (wxAuiNotebook) is triggered when any tab is clicked on Windows, but not on OSX (Cocoa) or Linux (GTK2). Is it a lucky coincidence that it works on Windows, or should it also work on OSX/Linux? It would be great if it could be made to work. I can open a separate ticket on this if it's not by design.

Paul.

Note: See TracTickets for help on using tickets.