wxGTK: Disabling wxTextCtrl loses background color

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

wxGTK: Disabling wxTextCtrl loses background color

kmccarty
Hi,

It seems that under wxGTK, disabling a wxTextCtrl, and then re-enabling it, causes the original background color to be forgotten.  E.g.:

  textCtrl->SetBackgroundColour(wxColour(0,0,255)); // blue
  textCtrl->Disable();
  textCtrl->Enable();
  // now the color is system default again

Shouldn't it be remembered?  This works as expected under wxMSW.  [I don't have access to wx on Mac so cannot test there.]  But in order to make sure that our text controls have the expected colors on Linux as well, we have to remember to once again call SetBackgroundColour() for any that might get disabled/reenabled depending on settings elsewhere in a dialog.

This is on RHEL6 with GTK+ version 2.24.23, but it's had this problem on wxGTK as long as I can remember ... am finally frustrated enough to ask about it :-)

Thanks,

--
Kevin B. McCarty
<[hidden email]>

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: wxGTK: Disabling wxTextCtrl loses background color

kmccarty
My apologies, I slightly misstated the problem.

Turns out that, in a class we have that derives from wxTextCtrl, there
is actually wxGTK-specific code that explicitly forces the background
color to the system color in an override of wxTextCtrl::Enable(bool)
when the argument is 'false'.

Looking into it, though, I found that the reason we added this code
long ago was that, if the wxTextCtrl has a non-default background to
begin with, then calling wxTextCtrl::Disable() on Linux leaves the
original background color the same.

That means that in wxGTK, there is NO VISUAL INDICATOR that the text
control is disabled.  This is (again) not the case on Windows.  Should
perhaps something be done about that for wxGTK?

Still seems a bit untoward to me, though I apologize for having
originally misunderstood the actual problem.

Thanks,

--
Kevin B. McCarty
<[hidden email]>





On Thu, Feb 23, 2017 at 10:03 AM,  <[hidden email]> wrote:

> Hi,
>
> It seems that under wxGTK, disabling a wxTextCtrl, and then re-enabling it,
> causes the original background color to be forgotten.  E.g.:
>
>   textCtrl->SetBackgroundColour(wxColour(0,0,255)); // blue
>   textCtrl->Disable();
>   textCtrl->Enable();
>   // now the color is system default again
>
> Shouldn't it be remembered?  This works as expected under wxMSW.  [I don't
> have access to wx on Mac so cannot test there.]  But in order to make sure
> that our text controls have the expected colors on Linux as well, we have to
> remember to once again call SetBackgroundColour() for any that might get
> disabled/reenabled depending on settings elsewhere in a dialog.
>
> This is on RHEL6 with GTK+ version 2.24.23, but it's had this problem on
> wxGTK as long as I can remember ... am finally frustrated enough to ask
> about it :-)
>
> Thanks,
>
> --
> Kevin B. McCarty
> <[hidden email]>
>
> --
> Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
>
> To unsubscribe, send email to [hidden email]
> or visit http://groups.google.com/group/wx-users



--
Kevin B. McCarty
<[hidden email]>

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: wxGTK: Disabling wxTextCtrl loses background color

oneeyeman
Hi, Kevin,
Can you reproduce that in the text sample?
Can you try Git HEAD?

Thank you.


On Feb 23, 2017 10:22 AM, "Kevin B. McCarty" <[hidden email]> wrote:
My apologies, I slightly misstated the problem.

Turns out that, in a class we have that derives from wxTextCtrl, there
is actually wxGTK-specific code that explicitly forces the background
color to the system color in an override of wxTextCtrl::Enable(bool)
when the argument is 'false'.

Looking into it, though, I found that the reason we added this code
long ago was that, if the wxTextCtrl has a non-default background to
begin with, then calling wxTextCtrl::Disable() on Linux leaves the
original background color the same.

That means that in wxGTK, there is NO VISUAL INDICATOR that the text
control is disabled.  This is (again) not the case on Windows.  Should
perhaps something be done about that for wxGTK?

Still seems a bit untoward to me, though I apologize for having
originally misunderstood the actual problem.

Thanks,

--
Kevin B. McCarty
<[hidden email]>





On Thu, Feb 23, 2017 at 10:03 AM,  <[hidden email]> wrote:
> Hi,
>
> It seems that under wxGTK, disabling a wxTextCtrl, and then re-enabling it,
> causes the original background color to be forgotten.  E.g.:
>
>   textCtrl->SetBackgroundColour(wxColour(0,0,255)); // blue
>   textCtrl->Disable();
>   textCtrl->Enable();
>   // now the color is system default again
>
> Shouldn't it be remembered?  This works as expected under wxMSW.  [I don't
> have access to wx on Mac so cannot test there.]  But in order to make sure
> that our text controls have the expected colors on Linux as well, we have to
> remember to once again call SetBackgroundColour() for any that might get
> disabled/reenabled depending on settings elsewhere in a dialog.
>
> This is on RHEL6 with GTK+ version 2.24.23, but it's had this problem on
> wxGTK as long as I can remember ... am finally frustrated enough to ask
> about it :-)
>
> Thanks,
>
> --
> Kevin B. McCarty
> <[hidden email]>
>
> --
> Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
>
> To unsubscribe, send email to [hidden email]
> or visit http://groups.google.com/group/wx-users



--
Kevin B. McCarty
<[hidden email]>

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re: wxGTK: Disabling wxTextCtrl loses background color

kmccarty

On Thursday, February 23, 2017 at 10:43:24 AM UTC-8, Igor Korot wrote:
Hi, Kevin,
Can you reproduce that in the text sample?


Sure.  For instance, in WX 3.1.0, in samples/text/text.cpp:

Immediately after line 1101, add this:

  m_text->SetBackgroundColour(*wxRED);
  m_text->Disable();

On Windows, the background of this widget (the one at top-left of the "text" sample dialog) is now rendered "disabled" light grey, whereas on Linux the background is red.

Now, an interesting further finding:  If I make a similar change to the m_multitext widget (at top center of the sample dialog), that one gets rendered in red on both Linux and Windows despite its disabled status.

So it seems that the inconsistency in how a text control is shown in the "disabled" state is not between Linux and Windows, but rather it is between Windows text controls with or without the wxTE_MULTILINE flag.  [Testing on Windows 7 for what it's worth.]  I guess this comes down to the differences between "rich text" versus "not rich" text control on Windows, then?

Since the widget that actually gets shown as "disabled" is the odd one out (non-rich text and Windows only), I guess it would be asking a lot on my part to request that all other cases be changed to exhibit the same behavior?  Oh well...

 
Can you try Git HEAD?


Sure, when I have a chance.

Thanks,

--
Kevin B. McCarty
<[hidden email]>
 

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|

Re[2]: wxGTK: Disabling wxTextCtrl loses background color

Vadim Zeitlin-4
On Thu, 23 Feb 2017 11:13:20 -0800 (PST)  wrote:

> On Windows, the background of this widget (the one at top-left of the
> "text" sample dialog) is now rendered "disabled" light grey, whereas on
> Linux the background is red.

 This doesn't necessarily mean this is wrong. wxWidgets strives to provide
the native behaviour, not the same behaviour under different platforms. I'm
pretty sure that the behaviour you see under MSW is native, and I suspect
that the one you see under GTK might be native as well, although I further
suspect this really depends on the theme.

> Now, an interesting further finding:  If I make a similar change to the
> m_multitext widget (at top center of the sample dialog), that one gets
> rendered in red on both Linux and Windows despite its disabled status.

 Again, under MSW I'm quite sure that this is the normal and expected
behaviour. I.e. disabled multiline edit/richedit controls in the other
Windows applications don't have grey background neither.

 Regards,
VZ

--
TT-Solutions: wxWidgets consultancy and technical support
               http://www.tt-solutions.com/

attachment0 (203 bytes) Download Attachment