LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Global of different scope for read and write

Solved!
Go to solution

Essentially I'm looking for a method of Private Write Public Read accessors without using a class.

 

Use Case (oversimplified)

 

Create a boolean that can only be true if the value is written by a member on a specific lvlib.

 

Think a vi in "Unit Test.lvlib in lvproj xxx" will allow me to set Unit Test Mode == True  and nobody else can call the vi that sets this value true such that Unit Test mode cannot be faked outside of unit test.

 

Or the functionality in this project WITHOUT LVOOP-

Any ideas?


"Should be" isn't "Is" -Jay
0 Kudos
Message 1 of 10
(3,232 Views)

Hi Jeff,

 

Something like this?

 

Untitled.png

Tom L.
0 Kudos
Message 2 of 10
(3,219 Views)

I'd rather break any vi that tries to set the value out of scope.


"Should be" isn't "Is" -Jay
0 Kudos
Message 3 of 10
(3,213 Views)

If it's in a LVLib, why not use the scoping functionality you have available there? Make your "set Unit Test True" VI private to the LVLib, and put the other functionality that you want to be able to access this VI in the same LVLib.

Message 4 of 10
(3,209 Views)
Solution
Accepted by JÞB

A better idea, using scoping. You can "befriend" the library, which implement Unit Test variable. This is actually fully OO code, but without using LVOOP 😉

Message 5 of 10
(3,203 Views)

@for(imstuck) wrote:

If it's in a LVLib, why not use the scoping functionality you have available there? Make your "set Unit Test True" VI private to the LVLib, and put the other functionality that you want to be able to access this VI in the same LVLib.


Nice one- I had an inkling that that was possible, but missed it this time around.

Regards,

Tom L.
0 Kudos
Message 6 of 10
(3,197 Views)

Greg's solution is definately the way to go.  By making the write VI and the global variable private inside of a lvlib, only VIs inside of that library can access them.  Any VI outside of the library that tries to call them will have a broken run arrow.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Message 7 of 10
(3,186 Views)
I had thought of the private set to the private gv but rejected it since a public read won't work. I'll. look at pidis example when I'm not mobile. kudos forthright.

"Should be" isn't "Is" -Jay
0 Kudos
Message 8 of 10
(3,155 Views)

I hadn't thought of a semiprivate friend for a second lvlib.

 

You gotta love the forums! Thanks

 

Pidi-  If you want a bunch more kudos toss some documentation in that and cross post it to the micro-nuggets thread.  That is an interesting solution to a tricky problem


"Should be" isn't "Is" -Jay
0 Kudos
Message 9 of 10
(3,135 Views)

Be careful with friending, some poeple have had issues when friending classes, although this may not apply to your specific situation. Just something to be aware of.

0 Kudos
Message 10 of 10
(3,113 Views)