tags:

views:

381

answers:

4

Let's say I've got a control and I want to prevent it from being edited.

Setting the Enabled property of the control to False will work but the control appearance will change accordingly, usually to a difficult to read black over gray font. When readability is still important, this is a real problem.

For a TextBox, there are a few obvious fixes :

Textbox1.BackColor = Color.White;

or

Textbox1.ReadOnly= true; // instead of setting Enabled to false

but unfortunately this won't work for every controls (eg radio buttons)

Another solution is to let the Enabled property untouched, and to subscribe to the focus event like this (but this isn't a really elegant solution)

    this.Textbox1.Enter += new System.EventHandler(this.Textbox1_Enter);

    private void Textbox1_Enter(object sender, EventArgs e)
    {
      Textbox1.FindForm().ActiveControl = null;
    }

Have you seen other ways of dealing with this problem? (and I mean real world solutions ; of course you can capture a screenshot of the control and display the copy over the control...:p)

A: 

Some controls can be set to ReadOnly which leaves them enabled, but unable to be changed. This may be what you're looking for.

That said you're probably going to be a world of hurt when your users start coming in confused because it looks like they should be able to edit the controls, but they can't. There's a reason they change their visual appearance -- it's to communicate the system's state to the user. Mess with that and they may end up very confused.

Orion Adrian
I posted before I was actually done with the question.
Orion Adrian
ahah ! Yet another reputation sniper :)
Brann
+3  A: 

There is an argument that interfering with standard Windows behaviour is confusing for the user, but that aside I have seen this done before, although more commonly in C++. You can subclass the control and handle paint messages yourself. When the control's enabled just delegate the drawing to the base class. When the control's disabled you can either let the base class draw itself and then do some custom drawing over the top or you can just draw the entire thing youself. I'd strongly recommend the first of these options.

Stu Mackellar
A: 

If a control is disabled/read-only then it really needs to look disabled/read-only. Otherwise, you are going to completely confuse the user.

There are very good reasons why Windows Controls behave the way they do and you really want to remain consistent with other Windows interfaces out there. When someone is using a Windows application they have certain expectations of how it should look and act.

If you deviate from these expectations then more often than not the user is going to think that your software is a piece of junk.

17 of 26
I globally agree with your point, BUT in some cases you really want to disable the control without altering its appearance (especially because the 'disabled' look is often difficutl to read). That's why the ReadOnly property is built into the framework for some controls, isn't it?
Brann
Yes, and the read-only property also causes a visual change to the control - it's just a different visual change.
17 of 26
A: 

Normally, Yes, do not want to change windows default behavior.

But I have a case where I am disabling many controls on a page, usually for less than a second, to avoid some cross-threading issues in a multi-threaded application. This causes major flickering issues as a user rolls through, say a treeview or listbox. NOT changing their appearance in this instance is a desirable thing.

However, when the controls are disabled for other reasons, I DO want their appearance to reflect their enabled/disabled state.

The flickering of the enabled/disabled states in the case where it is only a momentary thing actually results in a much more negative perception of the software more than the suppressing of the change in appearance for disabled controls to avoid flashing many parts of the form would.

T. Phaneuf