Button Forecolor When Disabled

[govolsbaby]

Is there a way to leave the button forecolor unchanged when it is
disabled?

I have multiple buttons on the form and depending on various user
inputs, some will or will not be enabled but I'd rather their text not
go to gray.

Thanks.

[Cor Ligthert[MVP]]

Luckily not, that is standard as users are now expecting it.

We are not living some years after WWII anymore.

Cor

<go********@gmail.comschreef in bericht
news:69**********************************@t41g2000 hsc.googlegroups.com...

Is there a way to leave the button forecolor unchanged when it is
disabled?

I have multiple buttons on the form and depending on various user
inputs, some will or will not be enabled but I'd rather their text not
go to gray.

Thanks.

[govolsbaby]

I'm not sure what to make of your comment. You know nothing of my
users, the purpose of my application, or the environment where it will
be deployed.

[Ken Halter]

<go********@gmail.comwrote in message
news:63**********************************@75g2000h so.googlegroups.com...

I'm not sure what to make of your comment. You know nothing of my
users, the purpose of my application, or the environment where it will
be deployed.

Disabled controls are supposed to have grey text! Just check *any
application in existance*... Disabled menus are grey, disabled option
buttons are grey, disabled checkboxes are grey. Even while typing this
reply, since I haven't selected anything for copy/paste, those buttons are
grey. Just hover your mouse over any menu.

This is a standard that was adopted pre-Windows 3.1, so your users, no
matter who they are, *should* be used to seeing grey buttons.

Now, if you insist on "breaking the rules", no one can stop you. You should
be able to place those buttons inside of a container control and disable the
container, instead of the button. Be prepared for support calls asking
questions like "The button looks available, but when I click it, nothing
happens"

--
Ken Halter
Part time groupie

[govolsbaby]

On Sep 30, 1:22*pm, "Ken Halter"
<Ken_Halter@Use_Sparingly_Hotmail.comwrote:

<[e-mail] in message

news:63**********************************@75g2000h so.googlegroups.com...

I'm not sure what to make of your comment. *You know nothing of my
users, the purpose of my application, or the environment where it will
be deployed.

Disabled controls are supposed to have grey text! Just check *any
application in existance*... Disabled menus are grey, disabled option
buttons are grey, disabled checkboxes are grey. Even while typing this
reply, since I haven't selected anything for copy/paste, those buttons are
grey. Just hover your mouse over any menu.

This is a standard that was adopted pre-Windows 3.1, so your users, no
matter who they are, *should* be used to seeing grey buttons.

Now, if you insist on "breaking the rules", no one can stop you. You should
be able to place those buttons inside of a container control and disable the
container, instead of the button. Be prepared for support calls asking
questions like "The button looks available, but when I click it, nothing
happens"

--
Ken Halter
Part time groupie

[govolsbaby]

Thank you Ken for giving me an idea on how to achieve what I'm after.

I think the problem here is that the so called "rules" typically apply
to desktop applications used in home/office environments by regular
people. This is not the case with my application. It is intended for
(and will only be used on) a specialized device by a very small (and
very highly trained) subset of the employee population of my company
in a very non-normal environment (especially in terms of lighting).

So why I can appreciate standards, there will always be exceptions.
This is one of those exceptions.

[Bill McCarthy]

"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.comwrote in message
news:e4*************@TK2MSFTNGP06.phx.gbl...

>
Now, if you insist on "breaking the rules", no one can stop you. You
should be able to place those buttons inside of a container control and
disable the container, instead of the button.

Did you actually fire up Visual Studio and test that ? I would be expecting
that not to work, rather the enabled status would cascade down to child
controls.

[Cor Ligthert[MVP]]

Bill,

Nobody prevents somebody to create his own controls.

However as you say: "I have made this with Visual Studio, then a kind of
standard behaviour is expected". Especially as you don't make it for kids.

It is for me as placing an engine from a Fiat Panda in a Ferrari and then
sell it as a standard Ferrari.

jmo

Cor

"Bill McCarthy" <Bi**@localhost.comschreef in bericht
news:e%****************@TK2MSFTNGP06.phx.gbl...

>
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.comwrote in message
news:e4*************@TK2MSFTNGP06.phx.gbl...

>>
Now, if you insist on "breaking the rules", no one can stop you. You
should be able to place those buttons inside of a container control and
disable the container, instead of the button.

Did you actually fire up Visual Studio and test that ? I would be
expecting that not to work, rather the enabled status would cascade down
to child controls.

[=?Utf-8?B?U3VydHVyWg==?=]

I for one hate this standard. It is very common to want a version of a data
entry form that is "read only".

Setting .Enabled=False would be the easiest way to do it, except that in
many cases the controls become unreadable. It is not very clear how Windows
decides what colours to use for these disabled controls.

It's okay that the colours change for disabled controls, what irks me is the
lack of control over what the colours change *to*.

I don't think Cor Ligthert's comment was useful at all. If you can't post
something polite and helpful, don't post at all.

--
David Streeter
Synchrotech Software
Sydney Australia
"Bill McCarthy" wrote:

>
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.comwrote in message
news:e4*************@TK2MSFTNGP06.phx.gbl...

Now, if you insist on "breaking the rules", no one can stop you. You
should be able to place those buttons inside of a container control and
disable the container, instead of the button.

Did you actually fire up Visual Studio and test that ? I would be expecting
that not to work, rather the enabled status would cascade down to child
controls.

[=?Utf-8?B?U3VydHVyWg==?=]

No easy way.

You can flip the .BackColor property between SystemColors.Control and (say)
Color.White depending on its .Enabled property to make it more readable.

--
David Streeter
Synchrotech Software
Sydney Australia
"go********@gmail.com" wrote:

Is there a way to leave the button forecolor unchanged when it is
disabled?

I have multiple buttons on the form and depending on various user
inputs, some will or will not be enabled but I'd rather their text not
go to gray.

Thanks.

[Bill McCarthy]

Hi David,

That won't work. You either need to override the enabled property and stop
it being disabled as such or override the OnPaint method and draw the text
yourself
"SurturZ" <su*****@newsgroup.nospamwrote in message
news:8B**********************************@microsof t.com...

No easy way.

You can flip the .BackColor property between SystemColors.Control and
(say)
Color.White depending on its .Enabled property to make it more readable.

--
David Streeter
Synchrotech Software
Sydney Australia
"go********@gmail.com" wrote:

>Is there a way to leave the button forecolor unchanged when it is
disabled?

I have multiple buttons on the form and depending on various user
inputs, some will or will not be enabled but I'd rather their text not
go to gray.

Thanks.

[Bill McCarthy]

Hi David,

The colors disabled controls change to is controlled by the sytem's color
schemes. Users can change these based on their monitor and/or visual
impairment they may have. There's also a standard set of schemes such as
high visibility etc. So if you do your own custom thing, you're fighting
against the system and the user ;)

That said, I know there are times you want to display information to the
user, but not allow interaction. I don't think a button is the right choice
there. One simple option might be to hide a button and instead show a label
or show a label over the button is the button is disabled.

Whatever approach you take, it really needs to be tested at a minim against
all the standard windows color schemes and themes (turn themes both on and
off). These days I also try to run the apps with a screen reader to make
sure there's no accessibility issues.

"SurturZ" <su*****@newsgroup.nospamwrote in message
news:E9**********************************@microsof t.com...

>I for one hate this standard. It is very common to want a version of a data
entry form that is "read only".

Setting .Enabled=False would be the easiest way to do it, except that in
many cases the controls become unreadable. It is not very clear how
Windows
decides what colours to use for these disabled controls.

It's okay that the colours change for disabled controls, what irks me is
the
lack of control over what the colours change *to*.

I don't think Cor Ligthert's comment was useful at all. If you can't post
something polite and helpful, don't post at all.

--
David Streeter
Synchrotech Software
Sydney Australia
"Bill McCarthy" wrote:

>>
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.comwrote in message
news:e4*************@TK2MSFTNGP06.phx.gbl...

>
Now, if you insist on "breaking the rules", no one can stop you. You
should be able to place those buttons inside of a container control and
disable the container, instead of the button.

Did you actually fire up Visual Studio and test that ? I would be
expecting
that not to work, rather the enabled status would cascade down to child
controls.

[Andrew Morton]

go********@gmail.com wrote:

Is there a way to leave the button forecolor unchanged when it is
disabled?

I have multiple buttons on the form and depending on various user
inputs, some will or will not be enabled but I'd rather their text not
go to gray.

What happens if you use RemoveHandler for its handlers instead of disabling
it, so you can still push it but nothing happens? Or, in the handler, do
nothing, depending on the state of a flag?

Or you could substitute the button with a picture of the button.

Andrew

[govolsbaby]

Okay so I ended up leaving the .Enabled property of the button set to
true. There were conditions for which I wanted this button to be
disabled, so I just added those conditions to the Click event for the
button. The code in the click event only executes when I want it to.

Also, I'm using .FlatStyle = Flat for my buttons. When the button is
available I had the .FlatAppearance.MouseDownBackColor
and .FlatAppearance.MouseOverBackColor set to something different that
the actual backcolor of the button. So when it's not available i
simply changed those two values to be equal to the button BackColor.

So unless certain conditions are met, no code executes on the click
and there is no visual feedback to the user that the button has been
clicked.

[Ken Halter]

"Cor Ligthert[MVP]" <no************@planet.nlwrote in message
news:3B**********************************@microsof t.com...

Bill,

Nobody prevents somebody to create his own controls.

However as you say: "I have made this with Visual Studio, then a kind of
standard behaviour is expected". Especially as you don't make it for kids.

It is for me as placing an engine from a Fiat Panda in a Ferrari and then
sell it as a standard Ferrari.

ummm... Huh? Panda? They still make Fiat's? Ferrari? Not sure what that's
supposed to mean, but... what ever floats your boat. I happen to drive a 4x4
truck.

jmo

Cor

"Bill McCarthy" <Bi**@localhost.comschreef in bericht
news:e%****************@TK2MSFTNGP06.phx.gbl...

>>
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.comwrote in message
news:e4*************@TK2MSFTNGP06.phx.gbl...

>>>
Now, if you insist on "breaking the rules", no one can stop you. You
should be able to place those buttons inside of a container control and
disable the container, instead of the button.

Did you actually fire up Visual Studio and test that ? I would be
expecting that not to work, rather the enabled status would cascade down
to child controls.

Isn't that beautiful... even more broken code and migration headaches. I
suppose people think that's just "wonderful", eh? geez... even the arrow
keys work differently when trying to position controls. "Glitter" instead of
functionality. Perfect.

btw, the Visual Studio I use daily "requires skill and knowledge"... isn't
that the favorite "I'm better than you" statement?. Some of that "knowledge"
says controls don't change their appearance simply because their container
is disabled. They never have. But, it's a "brave new world", right? Where
everything changes within a moments notice (or the next Windows Update)

--
Ken Halter
Part time groupie

[Bill McCarthy]

"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.comwrote in message
news:eZ**************@TK2MSFTNGP04.phx.gbl...

>>
"Bill McCarthy" <Bi**@localhost.comschreef in bericht
news:e%****************@TK2MSFTNGP06.phx.gbl...

>>>
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.comwrote in message
news:e4*************@TK2MSFTNGP06.phx.gbl...

Now, if you insist on "breaking the rules", no one can stop you. You
should be able to place those buttons inside of a container control and
disable the container, instead of the button.

Did you actually fire up Visual Studio and test that ? I would be
expecting that not to work, rather the enabled status would cascade down
to child controls.

Isn't that beautiful... even more broken code and migration headaches. I
suppose people think that's just "wonderful", eh? geez... even the arrow
keys work differently when trying to position controls. "Glitter" instead
of functionality. Perfect.

btw, the Visual Studio I use daily "requires skill and knowledge"... isn't
that the favorite "I'm better than you" statement?. Some of that
"knowledge" says controls don't change their appearance simply because
their container is disabled. They never have. But, it's a "brave new
world", right? Where everything changes within a moments notice (or the
next Windows Update)

Uhm, breathe Ken, breathe.
I take it from that hysteria posted above the answer to my question was no
you hadn't actually fired up Visual Studio and tested it.

As to your other comments, I guess you are trying to say the bad behavior of
VB6 not rendering buttons as disabled if the container is disabled is
somehow good because that's all you know ? In VB6 if you write code such as
Command1.Enabled = Not Command1.Enabled, no matter what your control won't
get rendered differently at runtime if the container is disabled. This goes
against the basic programming principles of the object defining it's own
appearance and windows guidelines. And what's even worse is if you set
Enabled to false at design time, then the button will be displayed as
disabled. But should you toggle that, you cannot get it back to that state
without first enabling the container. That's right, in VB6 with the
container disabled, you can go from button drawing as disabled to normal but
never back. Just because that's the behavior you know, does not make it
right. It's great .NET addressed those kind of issues properly.

[Cor Ligthert[MVP]]

Bill,

Here we normally don't behave as in the VB general discussions newsgroup.

We simply ignore people who throw mud.

As Sutur is consequently doing the same too me, as is done in the VB
general discussion newsgroup too you by some people, I would have expected
from you other behaviour.

Cor

"Bill McCarthy" <Bi**@localhost.comschreef in bericht
news:eG**************@TK2MSFTNGP02.phx.gbl...

Hi David,

The colors disabled controls change to is controlled by the sytem's color
schemes. Users can change these based on their monitor and/or visual
impairment they may have. There's also a standard set of schemes such as
high visibility etc. So if you do your own custom thing, you're fighting
against the system and the user ;)

That said, I know there are times you want to display information to the
user, but not allow interaction. I don't think a button is the right
choice there. One simple option might be to hide a button and instead
show a label or show a label over the button is the button is disabled.

Whatever approach you take, it really needs to be tested at a minim
against all the standard windows color schemes and themes (turn themes
both on and off). These days I also try to run the apps with a screen
reader to make sure there's no accessibility issues.

"SurturZ" <su*****@newsgroup.nospamwrote in message
news:E9**********************************@microsof t.com...

>>I for one hate this standard. It is very common to want a version of a
data
entry form that is "read only".

Setting .Enabled=False would be the easiest way to do it, except that in
many cases the controls become unreadable. It is not very clear how
Windows
decides what colours to use for these disabled controls.

It's okay that the colours change for disabled controls, what irks me is
the
lack of control over what the colours change *to*.

I don't think Cor Ligthert's comment was useful at all. If you can't post
something polite and helpful, don't post at all.

--
David Streeter
Synchrotech Software
Sydney Australia
"Bill McCarthy" wrote:

>>>
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.comwrote in message
news:e4*************@TK2MSFTNGP06.phx.gbl...

Now, if you insist on "breaking the rules", no one can stop you. You
should be able to place those buttons inside of a container control
and
disable the container, instead of the button.

Did you actually fire up Visual Studio and test that ? I would be
expecting
that not to work, rather the enabled status would cascade down to child
controls.

[=?Utf-8?B?U3VydHVyWg==?=]

I was actually thinking of textboxes rather than buttons. It seems silly to
me to re-write a whole new "read only" version of the form using labels
rather than simply setting .Enabled = False on all the textboxes. For
textboxes, .ReadOnly works I guess, but not all data entry controls have
..ReadOnly (comboboxes don't for example).

In any case, I am not sure which system color in the Windows control panel
is used for disabled buttons/textboxes. The control.ForeColor property does
not change when you disable a control (even though the ForeColor is obviously
changed to grey). There is a SystemColors.InactiveCaptionText but no
SystemColors.InactiveControlText

If anyone can tell me how to change the "disabled text" of a control to say
pink instead of grey, I would be most appreciative.
--
David Streeter
Synchrotech Software
Sydney Australia
"Bill McCarthy" wrote:

Hi David,

The colors disabled controls change to is controlled by the sytem's color
schemes. Users can change these based on their monitor and/or visual
impairment they may have. There's also a standard set of schemes such as
high visibility etc. So if you do your own custom thing, you're fighting
against the system and the user ;)

That said, I know there are times you want to display information to the
user, but not allow interaction. I don't think a button is the right choice
there. One simple option might be to hide a button and instead show a label
or show a label over the button is the button is disabled.

Whatever approach you take, it really needs to be tested at a minim against
all the standard windows color schemes and themes (turn themes both on and
off). These days I also try to run the apps with a screen reader to make
sure there's no accessibility issues.

"SurturZ" <su*****@newsgroup.nospamwrote in message
news:E9**********************************@microsof t.com...

I for one hate this standard. It is very common to want a version of a data
entry form that is "read only".

Setting .Enabled=False would be the easiest way to do it, except that in
many cases the controls become unreadable. It is not very clear how
Windows
decides what colours to use for these disabled controls.

It's okay that the colours change for disabled controls, what irks me is
the
lack of control over what the colours change *to*.

I don't think Cor Ligthert's comment was useful at all. If you can't post
something polite and helpful, don't post at all.

--
David Streeter
Synchrotech Software
Sydney Australia
"Bill McCarthy" wrote:

>
"Ken Halter" <Ken_Halter@Use_Sparingly_Hotmail.comwrote in message
news:e4*************@TK2MSFTNGP06.phx.gbl...

Now, if you insist on "breaking the rules", no one can stop you. You
should be able to place those buttons inside of a container control and
disable the container, instead of the button.

Did you actually fire up Visual Studio and test that ? I would be
expecting
that not to work, rather the enabled status would cascade down to child
controls.