Control became invisible in block diagram after moving it

[cebailey]

A control that was visible, and was supposed to be, on both the front panel and the block diagram, became invisible in the block diagram after I moved it. It is still visible on the front panel. If I doubleclick it on the front panel to be taken to its location on the block diagram, there is a "crawling" dotted outline showing a location on the block diagram, and this is located where I expect, and I can make it move using the arrow keys, but this outline is filled with white. If I left or right click on this empty outline or anywhere on the block diagram or the tools palette, the outline disappears.

This problem appeared when I moved the control a long distance on the block diagram by selecting it, shifting the diagram to the region I wanted to move the control to with the scroll bar, and then holding Shift-arrow key so the control would catch up with my new view. It did catch up as an empty crawling dotted outline. I've closed and reopened this VI but this behavior remains. I can't wire to this control because any mouse clicking makes it vanish. I can, however, wire to a local variable and Select this control from the list to associate the variable with this control.

Note this ISN'T a hidden control on the front panel. It's visible there and is supposed to be. I never did "hide control" on it. The problem is that it's invisible on the block diagram. I can't access the "hide control" feature for this anyway, because right clicking on it makes it disappear and gives me the Functions palette as if I clicked on an empty area of the block diagram.

Hiding of controls only refers to their appearance on the front panel, and there isn't supposed to be any way to hide a control on the block diagram, right? Or am I just forgetting something?

[TWGomez]

Its probably behind something. Post the vi and I can help fix it.

[falkpl]

Is the control behind a structure or off screen inside of a structure (Case with auto grow off)?  You should be able to move it a visible part of the diagram with a double click and then the arrow keys.  You might also consider the crude method, cut and then repaste the control and fix broken wires this often is the fastese method of findong an indicator which has gone fare off screen or gets lost in a structure)  Hide control is only true for fp objects but block daigram icons can be hard to find sometimes.

[cebailey]

>off screen inside of a structure

Falkpl, you got it.

It's a surprise to me that moving an unwired object out of a structure works differently depending on whether you drag it with the mouse or select it and move it with arrow keys. Dragging it with the mouse makes the object exist wherever you drop it, which in my case would have been outside all structures. Selecting it and moving it with arrow keys keeps the object logically inside the structure but beyond the structure's edges which makes it invisible.

I drove it back into the visible part of the structure with the arrow keys and then dragged it over the structure edge, and it's good now.

Thanks, both!

[Eriquito]

Hi cebailey, I agree that this seems like you would expect the arrow keys to function the same way as the mouse.  This was reported to R&D (# 125688) for further investigation.  Thanks for the feedback!

[altenbach]

---

Eriquito wrote:
Hi cebailey, I agree that this seems like you would expect the arrow keys to function the same way as the mouse.  This was reported to R&D (# 125688) for further investigation.  Thanks for the feedback!

---

NO!

The arrow keys should not allow objects to cross structure boundaries. The current behavior is correct!

If this would be changed, we would no longer be able to e.g. "float" controls over tab structures, for example.

[Eriquito]

Hi altenbach,

That is an interesting point.  I will add that information to the report I made..  perhaps R&D can find a way to allow that functionality while preventing objects from being accidently hidden behind structures (or perhaps they will decide to leave it as-is).  Thanks for the additional feedback!

[cebailey]

Shouldn't this depend on what the most reasonable or least surprising behavior of Windows is? I mean, it is fairly common for graphical Windows applications to let you move things either by dragging or by nudging with arrow keys. One could think of this as a part of Windows, rather than a part of programming LabVIEW. This is a philosophical point about user interfaces, but in discussing how a development environment should work, philosophical points about user interfaces are all important. And that is true whether or not at a detailed level it is the designers of Windows or the designers of the LabVIEW environment who are building the feature. In that light, wouldn't the least weird behavior be, when moving a graphical entity from one spot to another, that the method of moving doesn't matter? and ESPECIALLY that it doesn't matter in a way that isn't visible?

Whether nudging and dragging should have different final results is one question. Whether it is useful to float a control in front of a tabbed control without logically living inside it is another. The two don't have to be linked.

For that matter, here's a third: altenbach, why IS it useful to float a control in front like that? Could it be a surprising programming trick for which there are unsurprising and untricky alternatives? I don't mean this rhetorically - I really would like to know!

[johnsold]

The reason for floating a control in front of a tab is so that it is visible regardless of which tab page is selected.  It provides the appearance to the user that the same control is on each page without the complications of duplicate controls.

On your other point: LabVIEW is a multi-platform development environment and should not be tied to the methods of one o f the platforms.

The drag versus arrow movement is something which could be better documented at least.

Lynn 

[RavensFan]

---

cebailey wrote:

And that is true whether or not at a detailed level it is the designers of Windows or the designers of the LabVIEW environment who are building the feature. In that light, wouldn't the least weird behavior be, when moving a graphical entity from one spot to another, that the method of moving doesn't matter? and ESPECIALLY that it doesn't matter in a way that isn't visible?

---

I think the method of moving DOES matter.  They are actually two completely different methods going on that are a part of the Windows interface.  With arrow keys, you are essentially moving the the control.  But if you are using the mouse, you are actually calling Drag and Drop methods of the Windows interface.

Also think about the copying of the control.  If you hold down the Control key while dragging and dropping, you drop a copy of the control.  If you hold Ctrl and use the arrow keys, you are getting into controling the execution of the VI as those are shortcuts all defined under the Operate menu.

Just to show that arrow keys are inherently different from the drag and drop methods of the mouse.