Opened 3 years ago

Closed 17 months ago

#13495 closed defect (fixed)

wxSpinCtrl value not updated when closing the dialog containing it

Reported by: andrewtrevorrow Owned by:
Priority: normal Milestone: 2.9.5
Component: wxOSX-Cocoa Version: stable-latest
Keywords: regression wxSpinCtrl SetFocus Cc:
Blocked By: #14142, #14142 Blocking:
Patch: no

Description

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.

Change History (12)

comment:1 Changed 2 years ago by vadz

  • Milestone changed from 2.9.3 to 2.9.4

2.9.3 is already past

comment:2 Changed 2 years ago by disc

  • Status changed from new to confirmed

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.

comment:3 Changed 2 years ago by vadz

  • Milestone 2.9.4 deleted

Not 2.9.4-critical.

comment:4 Changed 20 months ago by vadz

  • Status changed from confirmed to infoneeded_new

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

comment:5 Changed 20 months ago by andrewtrevorrow

  • Status changed from infoneeded_new to new

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.
  1. 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".

comment:6 Changed 20 months ago by vadz

  • Milestone set to 2.9.5

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

comment:7 follow-up: Changed 18 months ago by vadz

  • Blocked By 14142 added
  • Status changed from new to confirmed
  • Summary changed from wxOSX-Cocoa bug: wxSpinCtrl doesn't get focus if SetFocus() is called in dialog ctor to wxSpinCtrl value not updated when closing the dialog containing it

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.

comment:8 in reply to: ↑ 7 Changed 18 months ago by 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.

comment:9 Changed 18 months ago by 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?

comment:10 Changed 17 months ago by csomor

  • Blocked By

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

comment:11 Changed 17 months ago by SC

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

comment:12 Changed 17 months ago by vadz

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

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

Note: See TracTickets for help on using tickets.