Place Global Variables as the actual variable when dragged from the GV window, not as a constant of that type.

[Neil.Pate]

 If you are using Global Variables in a project, and you drag the control from the Global VI's front panel to the block diagram of another VI, the item gets placed on the BD as a constant. It is more desirable that this action drop as a global variable node associated with the dragged control. If either the global VI in the project or the global VI's icon is dragged to a diagram then the result is a global variable node, but then always defaults to the first control in the global so you have to manually change it (this default choice is natural as LV would have no clue which control you wanted, fair enough).

This idea is to create some way of moving a control from the front panel of the global VI to the block diagram of another VI in such a way that LabVIEW knows to drop a global variable node instead of a constant. Because changing the standard behavior for dragging a control from any panel to any diagram would result in user interface inconsistencies, the suggestion is that ctrl+alt+drag be used to indicate that the user is performing a special drag, and when this drag is from the FP of the global VI to the diagram of another VI, LabVIEW should drop a global variable node.

Note: before I get people commenting that GVs are bad bad bad and should be removed, this idea does not attempt to rationalise the need for (or hatred of ) GVs, lets try and leave that for a different thread.

Message Edited by Laura F. on 10-07-2009 12:27 PM

[AristosQueue (NI)]

Copy/Paste and ctrl+drag are the same mechanism, and I do not think it would be at all desirable to make them behave differently. Thus, to make this change, you'd have to make the same change to Copy / Paste behaviors, and I don't think the confusion that would result would be desirable. I copy a control. Did I intend to copy the control or a reference to the VI that the control is inside such that when I paste it, I paste a global linked to that particular control? It would be really strange.

[JackDunaway]

AQ: Copy/Paste and CTRL+Drag are not always the same. Create a Local for Boolean, and CTRL+Drag it - as expected, you get another Local. Now, highlight a Local, and CTRL+V, and you get a brand new "Boolean 2" terminal, and a "Boolean 2" Local Variable. Well, just my 2cents, those two actions do not perform the same all the time (I would consider the behavior I mentioned unexpected and undesirable. New Idea?).

As for the behavior that nrp wants to change, I consider the current method expected and desirable. By the way, nrp, did you know that if the Global FP is open, you can drag the icon from the upper right hand corner onto your caller BD? Keeps you from needing to drag from the project tree when you're already looking at the Global FP. This should serve as a viable alternative for what you want to do, even though you still need to pick the right global.

And for anyone who balks at Globals just out of principle, I balk at you just out of principle.

Message Edited by JackDunaway (mechelecengr) on 09-30-2009 02:43 PM

[AristosQueue (NI)]

> Create a Local for Boolean, and CTRL+Drag it - as expected, you

> get another Local. Now, highlight a Local, and CTRL+V, and you get

> a brand new "Boolean 2" terminal, and a "Boolean 2" Local Variable.

Do ctrl+drag to another VI -- the behavior is the same as the cut/paste behavior. I should have phrased it as "cut/paste is equivalent to ctrl+drag to another VI". 

> (I would consider the behavior I mentioned unexpected and undesirable. New Idea?).

Creating the new boolean is the only option other than failing the paste entirely. You can't have a local variable with nothing for it to be local to. I wouldn't bother creating an idea for this change.

> This should serve as a viable alternative for what you want to do, even though you still need to pick the right global.

nrp notes that behavior when talking about dragging from the project. The need to still select which variable is exactly what his idea is aiming to eliminate. 

I think the idea would need some adjustment -- like perhaps using ctrl+alt+drag instead of just ctrl+drag, to indicate "this is the special drag mode that means drop a global node instead of a constant". Thoughts?

> And for anyone who balks at Globals just out of

> principle, I balk at you just out of principle.

Ah. I see you're one of those who believes that principles should never be used to actually guide your actions. 🙂 Out of curiosity, what other reason (besides principles) would someone use to balk at globals? *grin*

Message Edited by Aristos Queue on 09-30-2009 03:54 PM

[Neil.Pate]

JckDunaway, great tip, I did not know you could drag the icon!

Although this drops the wrong GV as you mentioned it is a nice compromise as it doesnt interrupt the work-flow too much (i.e. hunt around for the project window and then the GV VI in the window etc etc).

AQ: when dragging a control from on FP to another copies the control, what is the logic in creating a constant if it is dragged to the BD? This is actually something that has bugged me for a long time. If I copy a control from the BD of one VI, and want  to paste it into another VI  I have to change to the BD to paste it, it does not do anything if I CTRL-V (or drag) to the FP.

[AristosQueue (NI)]

The logic is simple: a constant and a control are both containers of data. You can "Change to Constant" and "Change to Control". So what is the representation of a control when copied to the diagram? A constant. It is a major boon to development... I frequently pause while writing my main VI in order to write a temporary VI to calculate some value and then copy the resulting indicator from the temporary VI to my main VI diagram. Gradient patterns, graphics transform matricies, complex physical constants... I use this a lot.

> If I copy a control from the BD of one VI,

There are no controls on the BD... so I assume you either mean copy a  constant or copy an FPTerminal.

Copying a constant to the FP does create a control.

Copying an FPTerminal does nothing because there is no meaningful representation of the FPTerminal on the panel. True, some users could see the terminal and the control as equivalent, but think about the ramifications... if those are equivalent, then copying an FPTerminal from the diagram and pasting it on the diagram would be ambiguous -- did you mean to paste a constant or a control? 🙂 The constant and the control are much more similar objects than the FPTerminal and the control, which are merely related objects.

The rules are very consistent and logically constructed. Other implementations are possible and would themselves be consistent,  but we pick one set and hold to it.

[Neil.Pate]

AQ: I have always seen the FPTerminal and the FPControl as absolutely equivalent, just residing in different domains.

To me, a copy of a control should always give another control, not a local or a constant

I would be more than satisfied with Cltr-Alt-drag as a special mode to drop GVs.

[AristosQueue (NI)]

I'll ask a moderator to amend your idea to include the ctrl+alt+drag.

[AristosQueue (NI)]

> AQ: I have always seen the FPTerminal and the FPControl as

> absolutely equivalent, just residing in different domains.

By that logic, a local variable and the FP control are equivalent, and some would say a linked property node to a specific control's Value property is also equivalent. 

Let me turn the question the other direction: if I copy a constant on the diagram and paste it on the panel, does that make sense to create a control? If so, why not the inverse?

[Laura F.]

nrp: please confirm the following text sent in by Aristos Queue for this idea - if it's fine with you, I will update the original idea text.

 If you are using Global Variables in a project, and you drag the control from the Global VI's front panel to the block diagram of another VI, the item gets placed on the BD as a constant. It is more desirable that this action drop as a global variable node associated with the dragged control. If either the global VI in the project or the global VI's icon is dragged to a diagram then the result is a global variable node, but then always defaults to the first control in the global so you have to manually change it (this default choice is natural as LV would have no clue which control you wanted, fair enough).

This idea is to create some way of moving a control from the front panel of the global VI to the block diagram of another VI in such a way that LabVIEW knows to drop a global variable node instead of a constant. Because changing the standard behavior for dragging a control from any panel to any diagram would result in user interface inconsistencies, the suggestion is that ctrl+alt+drag be used to indicate that the user is performing a special drag, and when this drag is from the FP of the global VI to the diagram of another VI, LabVIEW should drop a global variable node.

Note: before I get people commenting that GVs are bad bad bad and should be removed, this idea does not attempt to rationalise the need for (or hatred of ) GVs, lets try and leave that for a different thread.

[Neil.Pate]

Laura, that wording is fine, please modify the original idea. Thanks AQ.