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]]

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]

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

 

[Dan Tallent]

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]

Actually, you can place radio button, combo box in a group box, and set the
GroupBox.Enabled=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]

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

 

[Backwater Geezer]

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]

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]

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

dan

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]

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

 

[Jack Jackson]

[...]
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]

[...]
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.

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]]

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

 

[Dan Tallent]

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

I disagree. But more importantly, I suspect Microsoft disagrees. You
will just have to live with it.

That said...

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."

And? VB was never a shining example of good UI practices. If anything,
the fact that the feature was removed in the transition from VB to .NET
should suggest to you that someone actually put some thought into the
question rather than just blindly copying feature set to feature set.

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."

Again, FoxPro, not exactly the first place one should go to look for hints
as to best UI practices.

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

And this, is completely unrelated to your question. It has absolutely
nothing to do with UI presentation in dialog boxes.

I'd hardly say that you've succesfully demonstrated the supposed
ubiquitousness of this issue. If anything, you've demonstrated that as
the industry moves forward toward better, more-refined UI design, we've
learned our lessons from the past and are distancing ourselves from
user-hostile practices such as presenting ambiguous, misleading UI state.

Pete

So Pete,

Now it appears you are no longer claiming the missing feature is because of
lack of resources, but instead a decision made my Microsoft to elimate this
functionality.
If you don't have anything useful to add don't waste everyones time.

Dan

 

[Backwater Geezer]

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.

This is called "I don't care" approach.
If something is logical and can be achieved why not to implement it?

In your world object heavier than water would not float and transplants
would not exist.

And F-117 plane would not fly as its shape and aerodynamics violate
basic flying rules. Try to guess why despite this F-117 can fly.

MH

 

[Rune Huseby]

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.

Check out the AutoCheck-property for radiobuttons and combobox. Not sure
how you think a read-only combobox should behave. But propably you must
code that yourself.

 

[Backwater Geezer]

alll airplanes, including the F-117, comply with "basic flying rules"

Read

Nighthawk F-117: Stealth Fighter
By Paul F. Crickmore, Alison J. Crickmore