wxSpinCtrl value not updated when closing the dialog containing it

[andrewtrevorrow]

If a dialog is created with a wxSpinCtrl and SetFocus() is called on that control then no focus ring is displayed when the dialog appears.

To see the bug, run the dialogs sample, select Dialogs > Entry dialogs > Numeric entry. The spin ctrl's text box fails to have the focus even though there is a m_spinctrl->SetFocus() call in the wxNumberEntryDialog ctor code. No such problem in wxMac 2.8.12.

[vadz]

2.9.3 is already past

[disc]

This occurs because wxWidgetCocoaImpl::CanFocus returns false (even if Full Keyboard Access is on). As suggested in  this discussion removing wxWindowMac::AcceptsFocus does fix the problem, but is not a proper solution as mentioned by Stefan. I wanted to change CanFocus to use canBecomeFirstResponder but it's only available in iOS. Another possibility might be to do something like Carbon's wxMacControl::CanFocus which returns true if Full Keyboard Access is enabled.

[vadz]

Not 2.9.4-critical.

[vadz]

Could you please retest with the latest svn, notably after r72413?

[andrewtrevorrow]

The focus problem has been fixed, but r72413 seems to have introduced new bugs:

1. Run the dialogs sample, select Dialogs > Entry dialogs > Numeric entry and type in a number like 77, then hit OK. The resulting dialog says "You've entered 50" rather than 77, so something is wrong.

2. The new wxSpinCtrl class no longer has a GetTextValue() method. I know this was only available on wxMac/wxOSX but it was very handy. The GetValue() method is a bit stupid -- it always returns a valid int even if the user has entered an invalid number like "zzz".

[vadz]

I'll try to look at (1) next time I debug something under wxOSX.

As for (2), I agree such method would be useful but it really should be implemented for all platforms and not just wxOSX. Implementing it should be pretty simple everywhere...

[vadz]

Unfortunately I don't know how to fix this properly. I could fix the problem with pressing "Enter" but not with clicking the "OK" button with the mouse. We're supposed to get wxEVT_KILL_FOCUS in this case but we don't. I'm afraid we need to wait for Stefan to find time to deal with #14142.

[johnr]

Replying to vadz:

Unfortunately I don't know how to fix this properly. I could fix the problem with pressing "Enter" but not with clicking the "OK" button with the mouse. We're supposed to get wxEVT_KILL_FOCUS in this case but we don't. I'm afraid we need to wait for Stefan to find time to deal with #14142.

I worked around this in my code by subclassing wxNumberEntryDialog as NumberEntryDialog and using

In the constructor
Bind( wxEVT_COMMAND_BUTTON_CLICKED, &NumberEntryDialog::OnOKbutt, this );

and 

void NumberEntryDialog::OnOKbutt( wxCommandEvent& event )
{
#ifdef __WXMAC__
    if( event.GetId() == wxID_OK )
    {
        wxWindow* buttOk = FindWindow( wxID_OK );
        if( buttOk )
            buttOk->SetFocus();
    }
#endif
    event.Skip();
}

It doesn't fix the underlying problem but works.

[vadz]

So should we perhaps always set focus to the button being clicked in the code generating wxEVT_COMMAND_BUTTON_CLICKED, i.e. wxButton::OSXHandleClicked()? If your patch works, this should work too but I'm not sure if it's not going to result in some new bad side effects... Stefan, any idea?

[csomor]

(In #14142) with r73043 at least the window switches now trigger a focus lost as expected

[SC]

(In [73045]) simulating focus events, see #13495

[vadz]

This does seem to be fixed, at least the numeric entry dialog in the dialogs sample works as expected now, great!