Graying Out a Control without Disabling

[mploya]

Is there a way to gray out a control without disabling it?  The Disabled property node in a control allows you to programmatically Enable, Disable, or Disable and Gray Out.  I would like to be able to just Gray out instead of Disable and Gray Out.  Is there a property for controls like sliders, system radio buttons, numeric controls, and enums for this?

[tbob]

I don't think there is a property to just grey it out and not disable the control.  As an alternative, you could use the color properties to make it look greyed out.

[JÞB]

This would be possible with a strict type def that has been customized.  You would need to copy the images from the control's elements and edit them in another program (PowerPoint works) and set the pictures to look washed out.  Not really a programmatic way to do what you want.

For a programatic solution you would need to fool the UI by hiding a normal control and showing a second custom control with the washed out look and useing the value of the un-hidden control.  Pretty Ugly!

[mploya]

Thanks.  I tried changing the colors.  I was able to change the color of the text associated with the control to look grayed out but I could not get the actual control to look grayed out (for example the slider).  Maybe I was not using the correct property on the control (I tried using the Property Slider->Housing Colors but got an error).  Do you know how to change the color of the actual control (specifically radio buttons, sliders, numeric controls, and enums) to look grayed out?

[JÞB]

greying out isn't really about changing the color- it actually seams to change the transprancy of the front layers of an object (It seams like all objects have a solid grey base layer.)  But we have no access to the transparancy of individual control we only have access to the transparancy of the vi FP.

Without a guru "lifting the hood" the best we can do is guess and try to "fake" it

[Darin.K]

Just as a wild guess, I tried using an Event Structure.  Works better than expected for the slide, enum and system radio buttons.  Interesting behavior for the numeric control, you can use the increment/decrement buttons but can't enter a value directly.

On the one hand, an interesting experiment, on the other hand a word of caution.  One thing that really cheeses me off is non-standard GUI behavior.  Functioning controls which are greyed out fall into that category.

Now that you know how it is done, don't do it (IMO).

[JÞB]

OK Darin- I'm on the wrong home PC now --- the teaser is "intreging"-  what did you do?

[Darin.K]

In the Mouse Down? event I enable the control and in the Mouse Down event I diable and gray it out.

[JÞB]

Darin.  I would have spent days before I tried that approach!  NASTY behavior of the front panel.   I agree the experiment seams to reveal a bit about how the various components of controls are related and is worth some further "playing around" to peek under the hood a bit. 

More importantly- I totally agree with your "Don't do this!" caveat.  a user would barf if given a UI that responded that way.

[Ben]

---

@Darin.K wrote:

In the Mouse Down? event I enable the control and in the Mouse Down event I diable and gray it out.

---

But it works so well!

For the special case of the numerics, a cluge could use two controls to look like one and group them when done with the following.

The top one gets a transparent background.

The bottom one get set as disabled after setting the font color the same as the background color.

The bottom gives you control over the look while the top one provides the undersirable behaviour.

Ben

Snippet No work.  See attached code.