Windows application - read only

[Dan Tallent]

A textbox has a attribute for ReadOnly. This seems like such a simple
concept. When a textbox is set to read only the user cannot change the
contents of the field.

I have been trying to find that missing ability for other predefined
controls in C#. The radiobutton, checkbox, and combobox controls do not
share this ability. I find it difficult to believe that this feature was
left out and Microsoft expects everyone to write their own implementation of
these controls to handle the missing functionality.

Every control shares the attribute for Enabled. Unfortunately when the
control is rendered it is difficult to read when in a disabled state. I
have looked for a way to override this with little success.

Am I missing something or is the only way to have a ReadOnly ability on
other controls is to code this myself?

Thanks
Dan

[Cor Ligthert[MVP]]

Re: Windows application - read only

Dan,

The readonly property makes from a TextBox (with setting the appearance) a
kind of multiline label.

I don't see the purpose of that for a Combobox, a Ceckbox or a Radiobutton,
can you enlighten that missing for me.
In my idea would the use of readonly in these cases only make the customer
to report bugs.

Cor

"Dan Tallent" <spam@microsoft .comschreef in bericht
news:O$adsIWEJH A.4304@TK2MSFTN GP02.phx.gbl...

>A textbox has a attribute for ReadOnly. This seems like such a simple
>concept. When a textbox is set to read only the user cannot change the
>contents of the field.
>
I have been trying to find that missing ability for other predefined
controls in C#. The radiobutton, checkbox, and combobox controls do not
share this ability. I find it difficult to believe that this feature
was left out and Microsoft expects everyone to write their own
implementation of these controls to handle the missing functionality.
>
Every control shares the attribute for Enabled. Unfortunately when the
control is rendered it is difficult to read when in a disabled state. I
have looked for a way to override this with little success.
>
Am I missing something or is the only way to have a ReadOnly ability on
other controls is to code this myself?
>
Thanks
Dan
>
>
>
>
>
>
>
>
>
>
>
>
>

[Dan Tallent]

Re: Windows application - read only

There are times when you want to show information within these controls
however the user viewing the data does not have privledges to change. This
would be a good place to simply mark the controls as readonly which allow
the user to view but not change these settings. The developer (me) could
then write the user interface once and only have to mark the fields as
read-only as needed. IF you were to use other controls (textboxes) to
display the current value, now your producing a different UI for each
variation of the screen.

Example:
User A can change any of the values
User B can change all the values on the left side of the screen
User C can change all the values on the right side of the screen.
User D can NOT change any of the values.

4 different levels of permission but setting the correct controls to
readonly would easily handle this.

Does that help it make sense?

Dan



"Cor Ligthert[MVP]" <notmyfirstname @planet.nlwrote in message
news:350A37AF-8660-41E4-9C70-A0FF59948056@mi crosoft.com...

Dan,
>
The readonly property makes from a TextBox (with setting the appearance) a
kind of multiline label.
>
I don't see the purpose of that for a Combobox, a Ceckbox or a
Radiobutton, can you enlighten that missing for me.
In my idea would the use of readonly in these cases only make the customer
to report bugs.
>
Cor
>
"Dan Tallent" <spam@microsoft .comschreef in bericht
news:O$adsIWEJH A.4304@TK2MSFTN GP02.phx.gbl...

>>A textbox has a attribute for ReadOnly. This seems like such a simple
>>concept. When a textbox is set to read only the user cannot change the
>>contents of the field.
>>
>I have been trying to find that missing ability for other predefined
>controls in C#. The radiobutton, checkbox, and combobox controls do not
>share this ability. I find it difficult to believe that this feature
>was left out and Microsoft expects everyone to write their own
>implementati on of these controls to handle the missing functionality.
>>
>Every control shares the attribute for Enabled. Unfortunately when the
>control is rendered it is difficult to read when in a disabled state. I
>have looked for a way to override this with little success.
>>
>Am I missing something or is the only way to have a ReadOnly ability on
>other controls is to code this myself?
>>
>Thanks
>Dan
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>

>

[Peter Duniho]

Re: Windows application - read only

On Sun, 07 Sep 2008 20:22:55 -0700, Dan Tallent <spam@microsoft .comwrote:

[...]
I have been trying to find that missing ability for other predefined
controls in C#. The radiobutton, checkbox, and combobox controls do not
share this ability. I find it difficult to believe that this feature
was
left out and Microsoft expects everyone to write their own
implementation of
these controls to handle the missing functionality.

I always find it difficult to believe when people find it difficult to
believe that something was left out of .NET. :)

There are limits to the functionality that Microsoft can anticipate being
needed as well as that which Microsoft can devote resources to
implementing. People consistently underestimate the cost of even small
things, never mind features that significantly alter the behavior of the
UI.

As well, the functionality you're looking for is inconsistent with
standard UI practices. A read-only control is one that the user cannot
change, and by standard UI practices, that's a disabled control. The
"disabled" state of these controls is exactly the correct behavior when
the user cannot change them.

You'll note that in other applications, even when the controls are
disabled they are often used to display the current state of the control.
It's not really as difficult to read as you seem to think, but more
importantly, the disabled state provides critical feedback to the user as
to why user input on the control doesn't have any effect.

You could probably accomplish what you want, at least to some degree, by
simply watching for state changes and resetting to the desired value.
There's not really any need to rewrite the entire control. But however
you implement this behavior, you do so at your own risk. You're basically
asking to be able to disable a control without showing the user that it's
disabled. If you do that, be prepared for some very annoyed users.

Pete

[Dan Tallent]

Re: Windows application - read only

I always find it difficult to believe when people find it difficult to
believe that something was left out of .NET. :)
>
There are limits to the functionality that Microsoft can anticipate being
needed as well as that which Microsoft can devote resources to
implementing. People consistently underestimate the cost of even small
things, never mind features that significantly alter the behavior of the
UI.

The feature I'm describing existed in several programming languages and even
extended into application programs like Excel. This concept is not new or
rarely used.
If you don't believe me do a search on google for what I'm describing.

As well, the functionality you're looking for is inconsistent with
standard UI practices. A read-only control is one that the user cannot
change, and by standard UI practices, that's a disabled control. The
"disabled" state of these controls is exactly the correct behavior when
the user cannot change them.

A read-only control by default changes its appearance. A textbox will
change its backcolor to reflect it is non-editable. I am looking for the
exact same principle applied to other common controls. This UI practice
is the standard mechanism for displaying read-only, just look at the textbox
control.

You'll note that in other applications, even when the controls are
disabled they are often used to display the current state of the control.
It's not really as difficult to read as you seem to think, but more
importantly, the disabled state provides critical feedback to the user as
to why user input on the control doesn't have any effect.

As far as the difficulty reading the controls, you must put yourself in the
users position. Not everyone using your application will have perfect
eyesight and will struggle with the distored or faded look of a disabled
control. Do a search.. look this up for yourself if you don't beleive
how often this is a problem.

You could probably accomplish what you want, at least to some degree, by
simply watching for state changes and resetting to the desired value.
There's not really any need to rewrite the entire control. But however
you implement this behavior, you do so at your own risk. You're basically
asking to be able to disable a control without showing the user that it's
disabled. If you do that, be prepared for some very annoyed users.

"disable a control without showing the user that it's disabled"
Not true. I want the same effect as mentioned above that occurs on
textboxes.


With all of that said... I think the .NET framework is a wonderful
achievement, and obviously still growing. I make this post not to attack
MS but to try and find out how they expected us to write our applications
using these tools. I have read hundreds of articles, but these are always
based on how one person interpreted the development tool and is implementing
it within their application. Many of them are trying to write a work
around to this limitation. I am interested in how MS expected us to use
these tools. As I stated in my OP I assumed I was missing something. The
responses I've received so far are more defending MS position rather than
describing an alternate solution to the UI.


I appreciate any help that someone has to offer. I am not trying to
attack anyone, but if you offer an option don't be surprised if it is
questioned. This is the best way for our community to help the product
grow.

Thanks
Dan

[Norman Yuan]

Re: Windows application - read only

Actually, you can place radio button, combo box in a group box, and set the
GroupBox.Enable d=false. This way, the controls inside the group box will
still look as normal, but will not respond user clicks.

However, I have to agree with Cor, this is rather bad way of using controls.
Unless your form or your app prompt the user somewhere clearly that the data
he is viewing on the form is "Read ONly", the use may be very confused when
he is trying to click the "normal-look" controls but get nothing. If you
clearly want to show some read-only information, you have many ways to do it
rather than present it with a confusing controls (look normal but cannot do
anything).

"Dan Tallent" <spam@microsoft .comwrote in message
news:uu$ZBoWEJH A.5448@TK2MSFTN GP04.phx.gbl...

There are times when you want to show information within these controls
however the user viewing the data does not have privledges to change.
This would be a good place to simply mark the controls as readonly which
allow the user to view but not change these settings. The developer (me)
could then write the user interface once and only have to mark the fields
as read-only as needed. IF you were to use other controls (textboxes) to
display the current value, now your producing a different UI for each
variation of the screen.
>
Example:
User A can change any of the values
User B can change all the values on the left side of the screen
User C can change all the values on the right side of the screen.
User D can NOT change any of the values.
>
4 different levels of permission but setting the correct controls to
readonly would easily handle this.
>
Does that help it make sense?
>
Dan
>
>
>
"Cor Ligthert[MVP]" <notmyfirstname @planet.nlwrote in message
news:350A37AF-8660-41E4-9C70-A0FF59948056@mi crosoft.com...

>Dan,
>>
>The readonly property makes from a TextBox (with setting the appearance)
>a kind of multiline label.
>>
>I don't see the purpose of that for a Combobox, a Ceckbox or a
>Radiobutton, can you enlighten that missing for me.
>In my idea would the use of readonly in these cases only make the
>customer to report bugs.
>>
>Cor
>>
>"Dan Tallent" <spam@microsoft .comschreef in bericht
>news:O$adsIWEJ HA.4304@TK2MSFT NGP02.phx.gbl.. .

>>>A textbox has a attribute for ReadOnly. This seems like such a simple
>>>concept. When a textbox is set to read only the user cannot change the
>>>contents of the field.
>>>
>>I have been trying to find that missing ability for other predefined
>>controls in C#. The radiobutton, checkbox, and combobox controls do
>>not share this ability. I find it difficult to believe that this
>>feature was left out and Microsoft expects everyone to write their own
>>implementatio n of these controls to handle the missing functionality.
>>>
>>Every control shares the attribute for Enabled. Unfortunately when the
>>control is rendered it is difficult to read when in a disabled state.
>>I have looked for a way to override this with little success.
>>>
>>Am I missing something or is the only way to have a ReadOnly ability on
>>other controls is to code this myself?
>>>
>>Thanks
>>Dan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>

>>

>
>

[Dan Tallent]

Re: Windows application - read only

I'm not suggesting the controls would look normal. The background /
foreground colors would change when read-only just like textboxes do.

How would you display information to a user if they are not permitted to
change it ?

Dan


"Norman Yuan" <FakeName@FakeE mail.Notwrote in message
news:%23mFuclbE JHA.1460@TK2MSF TNGP03.phx.gbl. ..

Actually, you can place radio button, combo box in a group box, and set
the GroupBox.Enable d=false. This way, the controls inside the group box
will still look as normal, but will not respond user clicks.
>
However, I have to agree with Cor, this is rather bad way of using
controls. Unless your form or your app prompt the user somewhere clearly
that the data he is viewing on the form is "Read ONly", the use may be
very confused when he is trying to click the "normal-look" controls but
get nothing. If you clearly want to show some read-only information, you
have many ways to do it rather than present it with a confusing controls
(look normal but cannot do anything).
>
"Dan Tallent" <spam@microsoft .comwrote in message
news:uu$ZBoWEJH A.5448@TK2MSFTN GP04.phx.gbl...

>There are times when you want to show information within these controls
>however the user viewing the data does not have privledges to change.
>This would be a good place to simply mark the controls as readonly which
>allow the user to view but not change these settings. The developer
>(me) could then write the user interface once and only have to mark the
>fields as read-only as needed. IF you were to use other controls
>(textboxes) to display the current value, now your producing a different
>UI for each variation of the screen.
>>
>Example:
>User A can change any of the values
>User B can change all the values on the left side of the screen
>User C can change all the values on the right side of the screen.
>User D can NOT change any of the values.
>>
>4 different levels of permission but setting the correct controls to
>readonly would easily handle this.
>>
>Does that help it make sense?
>>
>Dan
>>
>>
>>
>"Cor Ligthert[MVP]" <notmyfirstname @planet.nlwrote in message
>news:350A37A F-8660-41E4-9C70-A0FF59948056@mi crosoft.com...

>>Dan,
>>>
>>The readonly property makes from a TextBox (with setting the appearance)
>>a kind of multiline label.
>>>
>>I don't see the purpose of that for a Combobox, a Ceckbox or a
>>Radiobutton , can you enlighten that missing for me.
>>In my idea would the use of readonly in these cases only make the
>>customer to report bugs.
>>>
>>Cor
>>>
>>"Dan Tallent" <spam@microsoft .comschreef in bericht
>>news:O$adsIWE JHA.4304@TK2MSF TNGP02.phx.gbl. ..
>>>>A textbox has a attribute for ReadOnly. This seems like such a simple
>>>>concept. When a textbox is set to read only the user cannot change the
>>>>contents of the field.
>>>>
>>>I have been trying to find that missing ability for other predefined
>>>controls in C#. The radiobutton, checkbox, and combobox controls do
>>>not share this ability. I find it difficult to believe that this
>>>feature was left out and Microsoft expects everyone to write their own
>>>implementati on of these controls to handle the missing functionality.
>>>>
>>>Every control shares the attribute for Enabled. Unfortunately when
>>>the control is rendered it is difficult to read when in a disabled
>>>state. I have looked for a way to override this with little success.
>>>>
>>>Am I missing something or is the only way to have a ReadOnly ability on
>>>other controls is to code this myself?
>>>>
>>>Thanks
>>>Dan
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>

>>
>>

>

[Backwater Geezer]

Re: Windows application - read only

Dan Tallent wrote:

The feature I'm describing existed in several programming languages
and even extended into application programs like Excel. This
concept is not new or rarely used. If you don't believe me do a
search on google for what I'm describing.

Well, you must be oldtimer.
Nowdays most of people are happy with what M$ provides.

A read-only control by default changes its appearance. A textbox
will change its backcolor to reflect it is non-editable. I am
looking for the exact same principle applied to other common
controls. This UI practice is the standard mechanism for
displaying read-only, just look at the textbox control.

I'm afraid some (younger) people won't understand such concept.

As far as the difficulty reading the controls, you must put yourself
in the users position. Not everyone using your application will
have perfect eyesight and will struggle with the distored or faded
look of a disabled control.

Sometimes I like "cannot be done" approach. Usualy on Fridays, five to
five.

"disable a control without showing the user that it's disabled"
Not true. I want the same effect as mentioned above that occurs on
textboxes.

I had to create a number my own control for ComboBox, the main control
is replaced by a label in ReadOnly state.
In case of RadioButton or CheckBox I used image + label.
Normal buttons are just visible/invisible.

MH

[Pavel Minaev]

Re: Windows application - read only


"Dan Tallent" <spam@microsoft .comwrote in message
news:%23%23anax bEJHA.5732@TK2M SFTNGP04.phx.gb l...

I'm not suggesting the controls would look normal. The background /
foreground colors would change when read-only just like textboxes do.
>
How would you display information to a user if they are not permitted to
change it ?

Without using checkbox or radio button, obviously :)

The thing is, if they aren't allowed to change anything, why even show any
other available options? For example, you may want something like this:

[x] Color tint
(_) Red
(x) Green
(_) Blue

But if user cannot change anything here, then why not just display instead:

"Green tint".

It conveys exactly the same information in a more straightforward manner,
and there's no mistaking that it can't be edited.

[Dan Tallent]

Re: Windows application - read only

Fair enough, but a different user has permission to change this information.
Do you suggest a different interface for each scenario?

dan



"Pavel Minaev" <int19h@gmail.c omwrote in message
news:O0Dio5bEJH A.3408@TK2MSFTN GP04.phx.gbl...

>
"Dan Tallent" <spam@microsoft .comwrote in message
news:%23%23anax bEJHA.5732@TK2M SFTNGP04.phx.gb l...

>I'm not suggesting the controls would look normal. The background /
>foreground colors would change when read-only just like textboxes do.
>>
>How would you display information to a user if they are not permitted to
>change it ?

>
Without using checkbox or radio button, obviously :)
>
The thing is, if they aren't allowed to change anything, why even show any
other available options? For example, you may want something like this:
>
[x] Color tint
(_) Red
(x) Green
(_) Blue
>
But if user cannot change anything here, then why not just display
instead:
>
"Green tint".
>
It conveys exactly the same information in a more straightforward manner,
and there's no mistaking that it can't be edited.
>

[Dan Tallent]

Re: Windows application - read only

Yea, I've been around awhile. I was expecting this feature to be part of
the core package since it has been around for years.

I appreciate the help.

Thanks
Dan




"Backwater Geezer" <geezer@eu.conw rote in message
news:u4hkb3bEJH A.1272@TK2MSFTN GP05.phx.gbl...

Dan Tallent wrote:
>

>The feature I'm describing existed in several programming languages
>and even extended into application programs like Excel. This
>concept is not new or rarely used. If you don't believe me do a
>search on google for what I'm describing.

>
Well, you must be oldtimer.
Nowdays most of people are happy with what M$ provides.
>

>A read-only control by default changes its appearance. A textbox
>will change its backcolor to reflect it is non-editable. I am
>looking for the exact same principle applied to other common
>controls. This UI practice is the standard mechanism for
>displaying read-only, just look at the textbox control.

>
I'm afraid some (younger) people won't understand such concept.
>

>As far as the difficulty reading the controls, you must put yourself
>in the users position. Not everyone using your application will
>have perfect eyesight and will struggle with the distored or faded
>look of a disabled control.

>
Sometimes I like "cannot be done" approach. Usualy on Fridays, five to
five.
>

>"disable a control without showing the user that it's disabled"
>Not true. I want the same effect as mentioned above that occurs on
>textboxes.

>
I had to create a number my own control for ComboBox, the main control
is replaced by a label in ReadOnly state.
In case of RadioButton or CheckBox I used image + label.
Normal buttons are just visible/invisible.
>
MH

[Peter Duniho]

Re: Windows application - read only

On Mon, 08 Sep 2008 05:32:05 -0700, Dan Tallent <spam@microsoft .comwrote:

[...]
The feature I'm describing existed in several programming languages and
even
extended into application programs like Excel. This concept is not new
or
rarely used.
If you don't believe me do a search on google for what I'm describing.

If there were specific examples, you would mention them by name. I'm
particularly confident that Excel doesn't violate this particular UI
convention in a dialog box, and frankly saying it exists in "several
programming languages" doesn't really make sense, as _none_ of the
mainstream programming languages know anything at all about UI. They all
rely on frameworks or system APIs to present a GUI.

In any case, the question isn't whether it's rarely used or not. It's
whether it's good UI practices, and whether even if it were, it would be
cost-effective for Microsoft to implement it.

I can play the "I've been around awhile" card as well as pretty much
anyone else here. I've been writing GUI code some twenty years, since
before there was even a viable version of Windows around. It's not going
to get you anywhere with me.

>As well, the functionality you're looking for is inconsistent with
>standard UI practices. A read-only control is one that the user cannot
>change, and by standard UI practices, that's a disabled control. The
>"disabled" state of these controls is exactly the correct behavior when
>the user cannot change them.

>
A read-only control by default changes its appearance. A textbox will
change its backcolor to reflect it is non-editable. I am looking for
the
exact same principle applied to other common controls. [...]

And it exists. It's called "disabling the control".

In any case, if you want to present information to the user in a way that
doesn't allow them to change it, but which doesn't look like a disabled
control that would otherwise allow them to change the information, find a
different way to present the information. You don't need to write a whole
new control for the purpose; there are dozens, if not hundreds, of
existing methods of presenting information to the user that don't involve
radio buttons, check boxes, or comboboxes.

Heck, if nothing else, you could just add a Label instance that presents
the current setting for whatever control is disabled.

It's not rocket science. Overloading the behavior of well-known,
well-understood controls is a recipe for user confusion. You claim that
you care about the user? Then don't violate the basic UI behaviors.
Don't introduce unusual, unpredictable behaviors to your application.

Pete

[Jack Jackson]

Re: Windows application - read only

On Mon, 08 Sep 2008 09:05:16 -0700, "Peter Duniho"
<NpOeStPeAdM@nn owslpianmk.comw rote:

>On Mon, 08 Sep 2008 05:32:05 -0700, Dan Tallent <spam@microsoft .comwrote:
>

>[...]
>The feature I'm describing existed in several programming languages and
>even
>extended into application programs like Excel. This concept is not new
>or
>rarely used.
>If you don't believe me do a search on google for what I'm describing.

>
>If there were specific examples, you would mention them by name. I'm
>particularly confident that Excel doesn't violate this particular UI
>convention in a dialog box, and frankly saying it exists in "several
>programming languages" doesn't really make sense, as _none_ of the
>mainstream programming languages know anything at all about UI. They all
>rely on frameworks or system APIs to present a GUI.
>
>In any case, the question isn't whether it's rarely used or not. It's
>whether it's good UI practices, and whether even if it were, it would be
>cost-effective for Microsoft to implement it.
>
>I can play the "I've been around awhile" card as well as pretty much
>anyone else here. I've been writing GUI code some twenty years, since
>before there was even a viable version of Windows around. It's not going
>to get you anywhere with me.
>

>>As well, the functionality you're looking for is inconsistent with
>>standard UI practices. A read-only control is one that the user cannot
>>change, and by standard UI practices, that's a disabled control. The
>>"disabled" state of these controls is exactly the correct behavior when
>>the user cannot change them.

>>
>A read-only control by default changes its appearance. A textbox will
>change its backcolor to reflect it is non-editable. I am looking for
>the
>exact same principle applied to other common controls. [...]

>
>And it exists. It's called "disabling the control".
>
>In any case, if you want to present information to the user in a way that
>doesn't allow them to change it, but which doesn't look like a disabled
>control that would otherwise allow them to change the information, find a
>different way to present the information. You don't need to write a whole
>new control for the purpose; there are dozens, if not hundreds, of
>existing methods of presenting information to the user that don't involve
>radio buttons, check boxes, or comboboxes.
>
>Heck, if nothing else, you could just add a Label instance that presents
>the current setting for whatever control is disabled.
>
>It's not rocket science. Overloading the behavior of well-known,
>well-understood controls is a recipe for user confusion. You claim that
>you care about the user? Then don't violate the basic UI behaviors.
>Don't introduce unusual, unpredictable behaviors to your application.
>
>Pete

The problem I have is that a ReadOnly textbox is visually very
different from a disabled ComboBox. It is much easier to read. In a
standard Windows installation the foreground and background colors
used in disabled controls are very close to each other, and I get many
complaints about how hard it is to read a disabled combobox.

I prefer to use a ReadOnly textbox instead of disabling it because it
is easier to read and so the user can copy the contents to the
clipboard, but with a mixture of different controls on a form it looks
strange since the comboboxes, checkboxes, etc. are harder to read.

Yes you can argue that this is easily fixable by the user, and that
the disabled comboboxes in my app look exactly like disabled
comboboxes in Windows apps, but in the end relatively naive users
don't care about that and don't want to monkey around with the Windows
display settings. They have trouble reading the comboboxes in my app
so it is my problem.

I have worked around this by adding a readonly textbox for each
combobox and making the appropriate one visible, but doing so is not a
trivial task when the combobox is databound. It would be nicer if
disabled controls weren't so hard to read by default.

[Dan Tallent]

Re: Windows application - read only

"Jack Jackson" <jjackson@cinno vations.netwrot e in message
news:jgkac4pmpl k59au6po0ur8eb2 6cmb7nlo9@4ax.c om...

On Mon, 08 Sep 2008 09:05:16 -0700, "Peter Duniho"
<NpOeStPeAdM@nn owslpianmk.comw rote:
>

>>On Mon, 08 Sep 2008 05:32:05 -0700, Dan Tallent <spam@microsoft .com>
>>wrote:
>>

>>[...]
>>The feature I'm describing existed in several programming languages and
>>even
>>extended into application programs like Excel. This concept is not new
>>or
>>rarely used.
>>If you don't believe me do a search on google for what I'm describing.

>>
>>If there were specific examples, you would mention them by name. I'm
>>particularl y confident that Excel doesn't violate this particular UI
>>convention in a dialog box, and frankly saying it exists in "several
>>programming languages" doesn't really make sense, as _none_ of the
>>mainstream programming languages know anything at all about UI. They all
>>rely on frameworks or system APIs to present a GUI.
>>
>>In any case, the question isn't whether it's rarely used or not. It's
>>whether it's good UI practices, and whether even if it were, it would be
>>cost-effective for Microsoft to implement it.
>>
>>I can play the "I've been around awhile" card as well as pretty much
>>anyone else here. I've been writing GUI code some twenty years, since
>>before there was even a viable version of Windows around. It's not going
>>to get you anywhere with me.
>>

>>>As well, the functionality you're looking for is inconsistent with
>>>standard UI practices. A read-only control is one that the user cannot
>>>change, and by standard UI practices, that's a disabled control. The
>>>"disabled" state of these controls is exactly the correct behavior when
>>>the user cannot change them.
>>>
>>A read-only control by default changes its appearance. A textbox will
>>change its backcolor to reflect it is non-editable. I am looking for
>>the
>>exact same principle applied to other common controls. [...]

>>
>>And it exists. It's called "disabling the control".
>>
>>In any case, if you want to present information to the user in a way that
>>doesn't allow them to change it, but which doesn't look like a disabled
>>control that would otherwise allow them to change the information, find a
>>different way to present the information. You don't need to write a whole
>>new control for the purpose; there are dozens, if not hundreds, of
>>existing methods of presenting information to the user that don't involve
>>radio buttons, check boxes, or comboboxes.
>>
>>Heck, if nothing else, you could just add a Label instance that presents
>>the current setting for whatever control is disabled.
>>
>>It's not rocket science. Overloading the behavior of well-known,
>>well-understood controls is a recipe for user confusion. You claim that
>>you care about the user? Then don't violate the basic UI behaviors.
>>Don't introduce unusual, unpredictable behaviors to your application.
>>
>>Pete

>
The problem I have is that a ReadOnly textbox is visually very
different from a disabled ComboBox. It is much easier to read. In a
standard Windows installation the foreground and background colors
used in disabled controls are very close to each other, and I get many
complaints about how hard it is to read a disabled combobox.
>
I prefer to use a ReadOnly textbox instead of disabling it because it
is easier to read and so the user can copy the contents to the
clipboard, but with a mixture of different controls on a form it looks
strange since the comboboxes, checkboxes, etc. are harder to read.
>
Yes you can argue that this is easily fixable by the user, and that
the disabled comboboxes in my app look exactly like disabled
comboboxes in Windows apps, but in the end relatively naive users
don't care about that and don't want to monkey around with the Windows
display settings. They have trouble reading the comboboxes in my app
so it is my problem.
>
I have worked around this by adding a readonly textbox for each
combobox and making the appropriate one visible, but doing so is not a
trivial task when the combobox is databound. It would be nicer if
disabled controls weren't so hard to read by default.

I could not agree more with Jack. The Enabled property would work
perfectly if it were easier to read.
If MS would supply a mechanism to change the disabled forecolor property it
would solve this issue.


You wanted some examples Pete, here you go. This feature is worth doing.

In this article MS talks about how they removed this functionality from VB

http://msdn.microsoft.com/en-us/library/fte6kbt2(VS.80).aspx

"Note In Visual Basic 6.0, setting the Locked property to True also
prevents the selection from being changed. You can duplicate this behavior
by canceling the selection in the MouseDown event."

In this article MS talks about how the readonly property works in Visual
Foxpro

http://msdn.microsoft.com/en-us/library/as80645b(VS.80).aspx

"The user cannot edit the control."

In this article MS talks about how you can open an Excel workbook as
readonly.

http://msdn.microsoft.com/en-us/library/microsoft.office.tools.excel.workbook.readonly(VS.80).aspx

Dan

[Cor Ligthert[MVP]]

Re: Windows application - read only

Jack.

and I get many
complaints about how hard it is to read a disabled combobox.
>

You know what to send to your customers at Christmass.

A screen cleaning set.

:-)

Cor