Enable Local Variables, References and Property Nodes for a Typedef to provide direct access to this Typedef

[X.]

Create a Control (or Indicator) and make it a typedef.

If you are like me, you will drop your control terminal in a dummy case structure that keeps all control/indicators tidily in a single location and only work with local variables, references or property nodes to access (read/write) this control.

But even if you are not like me, shouldn't you wonder why LV does not provide access to the Typedef from either Local Variables linked to the control (or indicator) or References to this control, or Property Nodes for this control?

The only way is to "Find" the terminal or control itself (which will potentially throw you in a parallel universe...I mean case in your main Action engine, for instance) and from there "Open Typedef". Of course you have to get back by your own means to the location which spurred the urge to look at that definition.

There is no fundamental justification to this limitation that I can think of. The reference, local variable and property nodes all know that they are associated with a typedef (check the contextual help when you hover over the objects or wires connected to them).

So, as the title says, Enable Local Variables, References and Property Nodes for a Typedef to provide direct access to this Typedef

[Intaris]

---

@X. wrote:

Create a Control (or Indicator) and make it a typedef.

If you are like me, you will drop your control terminal in a dummy case structure that keeps all control/indicators tidily in a single location and only work with local variables, references or property nodes to access (read/write) this control.

---

With the exception of this terrifying aspect of not using actual terminals for the precise function they were designed for, I agree with the rest of the text.

But seriously, do you mean this exactly as you wrote it?  It just sounds wrong.

But the right-click option on locals, globals and so on, absolutely.

[X.]

It is part use case illustration, part provocation.

I use this approach for my UI VIs. subVIs are much smaller and usually do not require this approach.

For UI VIs, I oftentimes find myself with tons of controls and indicators, and when I want to read from or write to one of them, I found it easier to put them all in a single case structure, where each case represents either a physical Tab on the FP or some logical part of the code. I clearly avoid doing this with graphs or otherwise large data structures or IF I use a terminal once and in a single location only. In general, as soon as I find using a control/indicator at two very distinct locations, I kick the terminal in the vault structure and replace it by a local variable (or a PN when I want to access a single element of a cluster, for instance). I pull a lot of wires already (IguessImightbeinfamousbynowwith my sequence structure as a rug suggestion), sohavingshiftregistersisnotalwaysanoption...

[fabric]

I'm with intaris... X: the idea is good but your intro is a bit idiosyncratic for me... I hope people read to the end! 🙂

[MarcoMauri]

I'm not like you,

but kudos to the idea!

[PaulG.]

I'm sort of like you. Most of my UIs function very well using event structures and locals. I also hate trying to keep track of every control and indicator in different cases. Like the rest of the idea, too. This idea of yours would make our way of doing things a little less "idiosyncratic". 

[altenbach]

Frankly, I don't really understand your problem, but would static control references be of any use?

[X.]

No problem. I'd just like to be able to jump to the typedef definition from anywhere it is used in EDIT MODE. And in fact, now that I think about it, it would be useful too to be able to access a typedef from a wire that transports it.

I am sure static control references are useful, but never found the need for one.