LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Kudoed Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Show hidden controls as "ghosts" in edit mode

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:

 

20779iD19E3A04FFDC0A31

 

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.


___________________
Try to take over the world!
40 Comments
Knight of NI

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! Smiley Happy

 

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.

Trusted Enthusiast

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.

Knight of NI Knight of NI
Knight of NI

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.


___________________
Try to take over the world!
Active Participant WNM
Active Participant

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.

Knight of NI Knight of NI
Knight of NI

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.


___________________
Try to take over the world!
Trusted Enthusiast

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.

Tim
Yanfeng, Global Automotive Interiors
Holland Michigan
Knight of NI Knight of NI
Knight of NI

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


___________________
Try to take over the world!
Proven Zealot

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

Knight of NI Knight of NI
Knight of NI

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.


___________________
Try to take over the world!
Trusted Enthusiast

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.