Allow scrolling in a disabled control

[gsussman]

When a control is disabled, especially a large table or string control, it would be nice if the scroll bar would remain active in order to view the contents of the control, without the ability to actually change it.

I am not asking that the default behavior be changed, however a right click property/property node "scroll when disabled" would certainly have some value.

[Technico]

I had already proposed this 5 years ago

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-vertical-center-for-string-indicators-and-don-t-di...

but afterwards realized it wasn't a good idea to have 2 ideas in one topic.

[AristosQueue (NI)]

Your use case is what an indicator is for -- a live UI element whose value you cannot change. "Disabled" means it is fully disabled with regard to the user interface. That's not something we're going to change.

[altenbach]

Sometimes the control/indicator distinction is a bit blurry. I sometimes have arrays of clusters of controls where some cluster elements are disabled because they are used as indicators where the value depend on the user entries of other cluster elements of the same array element. Since clusters cannot be mixed, these "indicators" need to be disabled controls. Because of the current limitation, they cannot be scrollable.

I agree that the current "disabled" behavior should not change, and that's why we should have a property to allow scrolling when disabled as suggested. I would use it. 🙂

[gsussman]

I agree with altenbach that the distinction between control and indicator is not always clear cut. In the instance of a test system you may have a control that is active during the test setup process but once the test starts, cannot be changed (disabled and grayed out). The user may still have a need to view the contents of the control (scroll up and down) but can not change any of the entiries.

[Benny.zhu]

    I do not know how to do that. I try to right click the property, but it did not exist.

So, could you tell me how to do this?

[altenbach]

>   I do not know how to do that. I try to right click the property, but it did not exist. So, could you tell me how to do this?

This is the idea exchange. If you need help with a labview problem, please start a new thread in the LabVIEW forum. Then also please explain what "that" is that you are trying to do, what you mean by "right-click the property", and what "it" is that does not exist. All these statements are very ambiguous!

[kegghead]

An indicator only provides this functionality if the user will never be required to edit the value. If you have to manage disabled state in response to the some other application state, it would be nice to allow the control to always be scrollable if that's the desired behavior.

A kludge is to have duplicate controls indicators at the same position and just show the appropriate one, but this really should be implemented.

[AristosQueue (NI)]

kegghead: I really fail to see how it is a kludge to have a control for when the user is doing data entry and an indicator for display-only. The visual styles of controls vs indicators are generally quite distinct. A user is likely to be confused about why they cannot type into something that looks like a typing field, or why they must type into something that doesn't look like a typing field. If you are implementing a user interface that flips from display-only to user-editable at various points, it would seem to me to be totally correct to hide one set of controls and show the other. Moreover, you would have distinct FPTerminals in the block diagram for the distinct sections of code dealing with these two distinct modes.

I have built many of those types of UIs. I have never felt that was a kludge. I have generally felt that was exactly the right way for LV to work -- I *liked* the organization that brought to my code, compared to some of my early UIs where I tried to make controls behave like indicators through use of local variables.

Has anyone else written code both ways? Does one clearly feel preferable to the other to you?

[altenbach]

> The visual styles of controls vs indicators are generally quite distinct.

You can re-use the same control/indicator for both, and for example in my "array of clusters" example above, I would color the background of the pseudo-indicators grey, hide the increment, and disable them. That should give enough visual clues. 😄

Similarly, that's what I do for my Xcontrols where the "direction change" changes these cosmetic properties. I don't like two sets (indicator + control) in the same FP location. It makes the panel hard to maintain (e.g. try to keep both aligned even if typically only one is visible at any given time).

[AristosQueue (NI)]

> (e.g. try to keep both aligned even if typically only one is visible at any given time).

I guess I don't worry about that too much since if it is a user visible panel, I have to have tons of layout code anyway to deal with font size changes from the OS... that code will line the controls/indicators up at runtime if they weren't saved that way.

I'm surprised especially that this works for you with XControls. I would have guessed there were enough *edit* time popup menus that differed between controls and indicators to make that not a viable approach.