Create Local Varaibles with the correct read/write attribute.

[Philbot]

When I right-click a Control or Indicator on the FP or BD, and select "Create / Local Variable" I always get a Writable Local Variable. This makes senser for an Indicator, but not a Control. It seems to me that if I create a Local Variable from a Control, it should default to being Readable, so I can wire it immedatley (rather than forcing me to "Change to Read" every time). Phil.

[Dennis_Knutson]

I disagree. When I create a local for a control, I typically want to write to it. If I want to read from the control, I read it directly - not from a local.

[Philbot]

If I could read the Control locally I would... but the reason I'm using a local variable is because I want to read the control's value from a sepparate loop/thread. That's what I was taught was their main function for existing... inter-thread communication. eg: using one stop button to halt two loops. You are using a local to write to a control to enable you to override the normal data flow model. OK, I see the value of this... but I'm surprised LV considers it to be the default usage for a local derived from a control.

[Dennis_Knutson]

Well, I remember when locals were introduced with the announcement that you can finally write to a control and read from an indicator. Since I seldom stop parallel loops with a global but constantly need to set controls to some value from ini files, I object to a blanket change of the existing behvior

Perhaps a user selectable option to change what type is created would be more appropriate.

[TCPlomp]

What about an easier way to change the direction?

Perhaps ctrl-click on a local variable would alter the direction.

Ton

[Intaris]

Or how about it automagically choosing read or write when actively wired to (but not when wires attached to it change their status - this would be a nightmare)

[Philbot]

"I remember when locals were introduced with the announcement that you can finally write to a control and read from an indicator". Interesting. Allthough I've got 35 years of programming experience I've only been using LabVIEW for 2 years, so my viewpoint is skewed by recent support material. All of the training examples I have seen, only use locals for intercommunication, rahter than overriding normal FP control usage: eg: http://zone.ni.com/reference/en-XX/help/lv/71/lvhelp/Writing_to_One_Front_Panel/ Thanks for pointing out this other (now obvious) application. Phil.

[JackDunaway]

Philbot, thanks for pointing out that article - I have nominated that "Help" Article into the Local Variable Hall of Fame. It demonstrates the top two most common mistakes in LabVIEW - a race condition and an uninhibited loop (which causes 100% CPU utilization). But instead of academically stating "don't do this!" it misleads the reader by failing to identify either programming faux pas.

[devicx]

I think Ton's suggestion works well, as a general-purpose solution.

My only addition to this idea is this (more of a reminder, really, as I'm certain it has been mentioned elsewhere):

Ctrl+click is an improvement, but really, this could be done during placement, as almost always, I know whether or not I'm going to switch to a "write local" then and there. (That is, I don't come back to the local weeks later and realize it should be a write instead of a read. Your workflow might, of course, differ.)

By way of example, the status quo, Ton's suggestion, and my suggestion follow:

Currently, I have to place the local, rmb over it, and select a context-menu option (requires three actions).

Placement followed by "ctrl+click" requires two actions.

Ctrl+place is a single action.

Of course, Ton's suggestion could be used to apply to a large number of locals at once, but that's another usage case.

In any case, Kudos for bringing this up. This has been a source of irritation, albeit a minor one, for many moons.

[sdubrul]

Kudos for easy changing the read/write behavior of a global var.

I would propsee hitting the key R or W to change it.

This would work during placement of the global or as well as when it's selected.

[Darren]

Any idea that has received less than 8 kudos within 8 years after posting will be automatically declined.