#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:
Priority: high Milestone:
Component: wxGTK Version: stable-latest
Keywords: wxTextCtrl wxCheckBox wxRadioButton Cc: jdagresta@…, juliansmart
Blocked By: Blocking:
Patch: no

Description

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:

  1. 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' ().
  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 ().
  3. Here's another manifestation: Now click twice on the Auto-save every checkbox. The '2' will be selected ().
  4. 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):

  1. Click on the third Good w/CB tab, then click on the Auto-save every CheckBox, and type '4' in the TextCtrl ().
  2. Click on another tab and then immediately click back on the third tab. The TextCtrl display is fine ().
  3. Click back to the first Bad w/CB tab and click on the Load last project on startup CheckBox ().
  4. 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:

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

Attachments (14)

dialogs.zip download (7.5 KB) - added by jdagresta 17 months ago.
Revised dialogs sample code to demonstrate the problem
initial.jpg download (22.7 KB) - added by jdagresta 17 months ago.
try1.jpg download (25.6 KB) - added by jdagresta 17 months ago.
try2.jpg download (27.0 KB) - added by jdagresta 17 months ago.
try3.jpg download (25.7 KB) - added by jdagresta 17 months ago.
try4.jpg download (26.9 KB) - added by jdagresta 17 months ago.
try5.jpg download (25.4 KB) - added by jdagresta 17 months ago.
try6.jpg download (25.3 KB) - added by jdagresta 17 months ago.
try7.jpg download (26.1 KB) - added by jdagresta 17 months ago.
try8.jpg download (27.8 KB) - added by jdagresta 17 months ago.
try9.jpg download (26.3 KB) - added by jdagresta 17 months ago.
dialogs.diff download (13.7 KB) - added by jdagresta 17 months ago.
Patch file to dialogs sample
dialog1.jpg download (57.8 KB) - added by jdagresta 13 months ago.
dialog2.jpg download (61.4 KB) - added by jdagresta 13 months ago.

Download all attachments as: .zip

Change History (24)

Changed 17 months ago by jdagresta

Revised dialogs sample code to demonstrate the problem

Changed 17 months ago by jdagresta

Changed 17 months ago by jdagresta

Changed 17 months ago by jdagresta

Changed 17 months ago by jdagresta

Changed 17 months ago by jdagresta

Changed 17 months ago by jdagresta

Changed 17 months ago by jdagresta

Changed 17 months ago by jdagresta

Changed 17 months ago by jdagresta

Changed 17 months ago by jdagresta

comment:1 Changed 17 months ago by jdagresta

  • Cc jdagresta@… added

comment:2 Changed 17 months ago by vadz

I'd really appreciate having just a patch to the sample in order to be able to see just what exactly was changed instead of having to read all the code myself. There is really no harm in keeping the parts of the dialogs sample that you don't need there, just unused. And it would make at least the initial analysis much simpler... TIA!

Changed 17 months ago by jdagresta

Patch file to dialogs sample

comment:3 Changed 17 months ago by jdagresta

Attached is dialogs.diff which is a patch to the dialogs sample.

You'll have to start the correct Dialogs > Property sheets > Standard property sheet dialog to get to the modified dialog with the tabs I've previously described and steps to reproduce the problem.

comment:4 Changed 16 months ago by jdagresta

Here is another way to manifest the wxTextCtrl display problem with the modified dialogs sample, but in this case only involving using a single tab of the wxNotebook dialog.

Go to the first tab (Bad CB) and follow step 1 (of my first post).

After entering text in the wxTextCtrl and without clicking on another tab of the wxNotebook, just type "Shift-TAB", "TAB", and then "Shift-TAB" and the wxTextCtrl field will incorrectly display as blank (matching picture in step 2 of my first post).

It seems that it has something to do with the text in the wxTextCtrl being "selected" - if there is an Enabling/Disabling association of the wxTextCtrl with a CheckBox or RadioButton then any selected text in the wxTextCtrl displays as blank when the focus gets placed on the CheckBox/RadioButton.

In following the above steps, when "Shift-TAB" is typed it shifts the focus back to the CheckBox but without any text of the wxTextCtrl selected since it has just been typed in (so display is fine), then typing "TAB" shifts the focus to the wxTextCtrl and selects all the text, and then typing "Shift-TAB" again moves the focus back to the CheckBox and because the wxTextCtrl text is selected it incorrectly displays as blank.

Changed 13 months ago by jdagresta

Changed 13 months ago by jdagresta

comment:5 Changed 13 months ago by jdagresta

  • Keywords wxNotebook removed
  • Summary changed from Redisplay problem with wxTextCtrl when used in wxNotebook dialog and associated with wxCheckBox or wxRadioButton to Redisplay problem with selected text in wxTextCtrl when associated with wxCheckBox or wxRadioButton

I found a way to manifest the wxTextCtrl display problem with the unmodified dialogs sample.

Run the dialogs sample. Click on Dialogs > Message Dialog.

Click to select the wxCheckBox next to "Yes". Click into the corresponding Custom label wxTextCtrl field. Type in some text (e.g. Yup). Select the text in that field.


Now just click in the Extended Message: box (with the "Yup" text still selected).

The "Yup" text entered for the Yes button is blanked out (invisible) - that is the display bug.


If you then ctrl+Tab twice to get back into the Yes Custom label wxTextCtrl field the "Yup" text will re-appear (still selected) or if you click back into that field the text will re-appear (unselected).

It appears that the display bug only occurs if there is a combination of a wxCheckBox (or wxRadioButton) that enables/disables the wxTextCtrl text entry box and when text in the text entry box is selected, and then the focus is moved to another field in the dialog.

I wonder if the display problem arises because the text is not first being unselected before the focus is moved to another field (which is how it behaves with wxMSW - although with wxGTK if there is not a wxCheckBox or wxRadioButton that enables/disables the wxTextCtrl then the selected text does not become invisible when the focus changes to another field)?

comment:6 Changed 13 months ago by vadz

  • Priority changed from normal to high
  • Status changed from new to confirmed
  • Summary changed from Redisplay problem with selected text in wxTextCtrl when associated with wxCheckBox or wxRadioButton to Contents of wxTextCtrl selection disappears on focus loss when the previous control is a wxCheckBox or wxRadioButton

I can confirm that the text indeed disappears but I have absolutely no idea why :-( The fact that it only does it when the text is next to a checkbox is particularly mysterious.

I don't really know where to start debugging this, we don't do anything special in focus-out event handler... The only solution is probably to forcefully reset selection to nothing in this handler.

Does anybody have any other ideas?

comment:7 Changed 13 months ago by ericj

It does not happen if you don't connect the wxEVT_UPDATE_UI event:

m_labels[n]->Connect(wxEVT_UPDATE_UI, ...

comment:8 Changed 13 months ago by vadz

  • Cc juliansmart added

Thanks a lot for noticing this! It allowed me to determine that this is due to the weird code in wxTextCtrl::OnEnabled() in wxGTK, trying to understand what exactly is this for... Not much hope here but, Julian, would you remember why did you need to do this in r10179? E.g. how can the problem this change was supposed to fix be reproduced?

comment:9 Changed 13 months ago by vadz

P.S. I simply don't see why would all this OnEnabled() stuff be needed at all, so I'm going to remove it entirely if there are no objections. And it does fix the original bug (assuming wxCheckBox was really a red herring and the real problem is simply due to the use of EVT_UPDATE_UI which is often used with checkbox-controlled text entries).

comment:10 Changed 13 months ago by VZ

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

(In [73756]) Remove wxTextCtrl::OnEnabled() hack from wxGTK.

Don't change the background colour when the control is being enabled or
disabled, it doesn't seem necessary and it's unclear why was this added by
r10179 in the first place. It does result in problems however as it could
somehow make the selection of wxTextCtrl invisible when it lost focus and so
fixes a serious usability problem which happened to all wxTextCtrls for which
a wxEVT_UPDATE_UI handler using wxUpdateUIEvent::Enable() was defined.

Closes #14898.

Note: See TracTickets for help on using tickets.