Show hidden controls as "ghosts" in edit mode

[tst]

I occasionally hide controls on my FP and control their visibility programmatically during the execution of my program. The problem is that if I edit my UI and the control is hidden, it's very easy not to be aware that it's there and to accidentally overlap it, hide it or even move it off the screen.

To solve this, I usually try to save the VIs with all the controls visible, but that's not always feasible.

A better solution - LabVIEW should always show hidden controls in edit mode. It should just have some way of differentiating them from visible controls. This mockup shows them as ghosts, but it can also be any other solution:

In run mode, of course, the control would not be shown. This is similar to the black border you get when objects overlap a tab control.

[altenbach]

I agree this is good. Maybe instead of "greyed out", they could be "pinked out" or some other tinted transparency.

This will make VIs of locals abusers (creating tons of invisible FP objects just to use them as "variables" on the BD) a little uglier. Probably a good thing! 🙂

Also, if we print the front panel in edit mode, should they be printed? Maybe Yes!?

We might have a problem with clusters that have a few invisible elements and are sized to fit or arranged automatically. Where should the hidden controls show? They should definitely not resize the container between run and edit mode.

[Intaris]

This should definitely be "always on".  I find the depth of options already available overwhelming. This is an improvement, let's be rid of the old way of doing things.

[tst]

I would say that if you have clusters which are set to auto-fit and have invisible elements - don't show those elements. Maybe it should even not affect hidden elements inside clusters at all, even if the cluster is not set to auto-fit? If it would show them, it might have to resize the cluster, which is bad. Maybe it could just mark those clusters as having hidden elements? The basic point here is not so much to show you all the options as it is to make sure you don't forget something. If the cluster itself is visible on the FP, you won't forget it even if some of its elements aren't visible.

As for printing, I don't usually print myself, but I believe printing always shows the FP as it is in run mode (no grid, no shadows). This should behave in exactly the same way.

[WNM]

This is something that I strongly feel SHOULD have a toggle. Some GUIs I've built have had context-sensitive stacked controls/indicators whose visibility was programmatically managed. Dealing with a pile of stacked F.P. items would become very difficult if they were all sitting on the panel and subject to selection in the edit mode.

[tst]

That's certainly a valid point, but it's also possible that this can be dealt with using alternative means. For example, maybe it would be possible to "flip" through stacked controls which are under the cursor using something like Ctrl+mouse scroll. I'll let NI figure that one out.

[aeastet]

I generally do not hide controls any more because it was a pain to find them and then you had to go through the trouble of showing them to chagne them then hide them again. I usually have a place on the user interface where I store controls and indicators that the operator is not going to touch. I like the idea but I think our programming has evolved around this problem.

[tst]

> I usually have a place on the user interface where I store controls and indicators that the operator is not going to touch. I like the idea but I think our programming has evolved around this problem.

This is not meant for controls the user will not touch. As you suggest, those can simply be placed off screen and then their appearance matters less (although in "proper" LV programming you usually shouldn't have them, unless they're I/O terminals on a subVI). This idea is targetted at controls and indicators which are part of the UI and which have their visibility controlled at run-time. Your programming may have somehow evolved to not require them, but it's a common UI behavior.

[muks]

I would be ok if we can get a toggle view of this!!!

[tst]

Whoever gets to evaluate this, should also have a look at this idea.

The generalization of this idea should be that anything which is invisible during run-time should have some visible edit-time representation.

Since some people seem to want to disable this, one option for that would be to add a section to the LV options which allows you to control the edit time visibility of each component which supports this. That way, each user could enable or disable this globally.

[Wayne.C]

tst,

I really like this idea.  I personally don't see the need for the toggle in edit mode.  The trick will be the appearance/color in edit mode.  I don't think that the greyed out look is the best. I was thinking a color that sharply contrasts with the background it appears on.  Not sure how this would affect color blind users so it probably needs some texture/dashed lines as well.