Any change in Global Variable data will trigger an application event that can be captured on any event structure on any VI.
What kind of perceived problem are you trying to solve with this? Just wondering...
Sounds like a User Event would be a better choice.
The ability to statically declare User Events (similar to a static VI reference) would be a nice feature to have in LabVIEW, and I can see leveraging a global VI-like syntax to add such a feature. So the idea has some merit insofar as the underlying functionality is a good request.
Having said that, we do not generate value change events on programmatic writes to any control in LabVIEW. This prevents the infinite echo chamber existing in many programming language UI systems. To generate such events, use user events*. I don't think it would be a good approach to add programmatic generation of these events to the controls/indicators of a global VI as that would potentially recreate the echo chamber but at a higher level of programming. I would also hesitate at any approach that adds a "good" use of globals as that would cloud our general message that "global VIs should be avoided whenever possible."
For now, since LabVIEW does not have static User Event declaration, crossrulz is right -- you probably should be looking at creating a User Event refnum in your root VI and passing it into both the subVI that is doing the change of value and the VI that needs to know about the value change, and then delete the global VI entirely. yschwarz@RSI, I do not know your particular application, so perhaps you have a good reason for using globals, but as soon as you start needing event signaling for their values, you've strayed into the types of applications that generally behave better when the globals are eliminated.
* Tangent: I am not certain but I believe that if you were to dynamically register for the Value Changed event on the Global VI's control, I believe you would get messaged for a user editing that value on the Global VI's panel. You would have to test that to be certain.
Well, I don't use the global variable on my app. I implemented functional global with user event for value change.
The reason for my suggestion is on streamline the app and reduce footprint. I have an application that is GOOP based with doesen subsystems. It getting to the point that to pass global data across my subsystems, like user settings I need to set a subsystem with class and extra 40 VI's, something that can be achived easaly with a functional global with 3 VI's.
If Labview would have a build-in event for value change on global variable I could decide if to use this event or not, and will not need to add any VI's to my application.
This could reduce memory and simplify programing. Yes global settings not follows "Data flow programing" but we all find different solutions for global settings one way or another.
Your use case is a good one, I'm just not sure that global VIs are the preferred way to solve it. But I do see the issue and agree it is worth time/effort to find a solution.
In the meantime VI Registers will solve your problem. These can behave as globals that you can register value update events for.
Any idea that has not received any kudos within a year after posting will be automatically declined.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.