Ticket #14898 (closed defect: fixed)
Contents of wxTextCtrl selection disappears on focus loss when the previous control is a wxCheckBox or wxRadioButton
|Reported by:||jdagresta||Owned by:|
|Keywords:||wxTextCtrl wxCheckBox wxRadioButton||Cc:||jdagresta@…, juliansmart|
There is a (re)display problem in wxGTK when there is a wxTextCtrl in a wxNotebook dialog that is associated with a wxCheckBox or wxRadioButton in the same dialog (associated in that the setting of the CheckBbox/RadioButton controls whether the wxTextCtrl is enabled or not).
I've reproduced the problem using wxGTK on Solaris, AIX, and Red Hat Linux platforms.
Attached is dialogs.zip which contains samples/dialogs/dialogs.h and dialogs.cpp, a modified (and very stripped down) version of the dialogs sample to demonstrate the problem. It has one option (other than Exit) on the File menu to display a Standard property sheet wxNotebook dialog with four tabs (). Take a copy of the samples/dialogs directory and replace dialogs.h/dialogs.cpp with my versions and make the dialogs demo program.
The first tab (Bad w/CB) demonstrates the display problem using a wxTextCtrl associated with a wxCheckBox. The second tab (Bad w/RB) is a wxTextCtrl associated with a wxRadioButton.
The other two tabs (Good w/CB and Good w/RB) are almost identical as the first two tabs, except the wxTextCtrl is not associated with the CheckBox/RadioButton - the wxTextCtrl is always enabled.
Here are the steps with the sample program to reproduce the display problem:
- Bring up the Notebook dialog (first Bad w/CB tab) and click on the Auto-save every checkbox. Cursor will move to wxTextCtrl. Type in '2' ().
- Without typing or clicking on anything else, click on another tab of the notebook and then immediately click back on the first Bad w/CB tab. Notice that the TextCtrl is blank (). This is the display bug. Click in the TextCtrl and the '2' will appear ().
- Here's another manifestation: Now click twice on the Auto-save every checkbox. The '2' will be selected ().
- Click on another tab and then immediately click back on the first tab. The TextCtrl is again blank (). Click on the TextCtrl and the '2' will appear ().
Same display problem can be demonstrated with the second Bad w/RB tab which uses a TextCtrl associated with a RadioButton instead of a CheckBox.
Now some steps to show when the display problem does not happen (may help in diagnosing where exactly the bug occurs):
- Click on the third Good w/CB tab, then click on the Auto-save every CheckBox, and type '4' in the TextCtrl ().
- Click on another tab and then immediately click back on the third tab. The TextCtrl display is fine ().
- Click back to the first Bad w/CB tab and click on the Load last project on startup CheckBox ().
- Click on another tab and then click back to the first tab. The display bug with the TextCtrl does not occur ().
So it seems like there have to be two things going on in order for the TextCtrl display bug to happen when you click on another tab and click back on the original tab:
- There has to be an association of Enabling/Disabling of the TextCtrl with choosing the CheckBox/RadioButton (Bad tabs). If the TextCtrl is always enabled (Good tabs), then the TextCtrl display problem does not occur.
- The focus has to be returned to the TextCtrl (or CheckBox/RadioButton) when you click back to the original tab. If the focus gets set to some other widget on the dialog (like in step 7 above), the TextCtrl display problem does not occur.
In the code you will see calls to SetFocus() in the BUTTON_CLICKED/RADIOBUTTON_SELECTED event handlers, but the display bug(s) still occur if those calls to SetFocus() are commented out, so the problem is not being caused by those calls.
Also interesting was that if the wxTextCtrl is instead a wxSpinCtrl, the same display bug does not occur.