Bug: Control is an Indicator? Sort of?

[jvon20]

I have two G Web projects - Project 1 has a string control which I also write to in my code in certain cases (to do this I created a duplicate terminal for the control which enables me to set the original terminal to write-mode). Anyways, if I copy the string control from the Panel of project 1 and paste it to the Panel of project 2, (from now on I'm only referring to Project 2) the Panel view thinks the pasted control is a control (and it appears as a control, with white background), but the Diagram thinks it is an indicator and has it being in write-mode (terminal on the left).  (Note that there is only one instance of the variable on the Diagram, as far as I can tell, unlike in Project 1, which has two because of the duplicate terminal). In Diagram view if I change the string variable (I am going to call it a variable since it is not clear if it is a control or an indicator) to be a control, it changes to read-mode/terminal on the right, and the Panel object maintains its control appearance (white background).  This is expected behavior. Then on the Diagram if I set the variable to be an indicator, it changes back to write-mode/terminal on the left, and the Panel object becomes an actual indicator, including with a dark background.  This is also expected behavior.  It is only the initial pasting of the Panel string control which has a duplicate write-mode terminal which is unexpected.

NOTE! This is only reproducible if the original string control is the terminal set to write mode in Project 1. If only the duplicate terminal is set to write-mode, then this issue does not occur.

G Web Development Software Version: 2021, Build 9.1.0.50238, Full Edition.

[sbasavaraj]

Thank you for bringing this issue to our notice. I have created a bug to take a look into this issue.

[Christina_R]

The described behavior is actually intended. I don't recommend that you use "duplicate terminals." You can initialize control values using the Value property.

Duplicating a terminal puts the control/indicator into a strange state, where it doesn't fully behave as a control or an indicator, but the editor doesn't make this very clear. The "duplicate terminal" concept was introduced into LabVIEW NXG (which has been discontinued), but the UX issues were never fully resolved.

It's possible we may deprecate this concept in G Web Development Software eventually, although we'd have to mutate existing customer projects to maintain their functionality.

[jvon20]

Wow, I did not realize there was another way to set the control values!  That is definitely an important feature to be able to do, and I thought that creating a duplicate terminal was the only way.  

The process/name of creating a "duplicate terminal" in G Web did strike me as odd. Why not simply "create local variable", like in LabVIEW? LabVIEW local variables are extremely useful when used carefully and appropriately - more efficient than property nodes, and less visually cluttered than wiring lines + shift registers everywhere.

Using a G Web property node to update a value is somewhat visually clumsy compared to duplicate terminals (or local variables). The attached WebVI image illustrates this. My two cents is that it would be nice to keep something that behaves just like the local variables in LabVIEW.

[bhpowell]

---

LabVIEW local variables are extremely useful when used carefully and appropriately - more efficient than property nodes

---

I know _nothing_ about performance of NXG or GWeb applications, but I wouldn't jump to the conclusion that property nodes would be less efficient than local variables in either environment.

Even in CurrentGen, the difference is subtle and relevant only when the front panel is not being displayed.

I do agree with wanting solutions that avoid using a lot of block diagram visual space, but on the other hand, just because CurrentGen has multiple ways to do something doesn't mean that GWeb should have all the ways, too.

I guess my message to NI R&D is that in the G Web software, usability is more important than LabVIEW compatibility.  Less diagram space is part of that, but so is speed of the editor, filling in missing functions, control customizability, and making "web stuff" easier. All are higher priority to me.