LabVIEW
Event Structure not firing when value changed via ActiveX
I have a 3rd party program that interacts with LabVIEW VIs via ActiveX. In this situation LabVIEW is the ActiveX Server and my 3rd party program is the ActiveX client. I just discovered some interesting behavior: If my VI has a control registered for a 'Value Change' event (lets say its a Boolean) and the 3rd party program changes said Boolean from FALSE->TRUE via ActiveX, the event stucture will NOT fire even though the Boolean value DOES change from FALSE->TRUE.
I don't know if this is a bug or a limitation with LabVIEW & ActiveX but what it means for me is that I cannot use an event-based architecture but rather I must poll on the front-panel controls to detect value changes which is something I want to avoid.
One half-baked solution I thought about implementing was having an introspective VI that queries it's parent for its list of front panel controls and polls on them to detect changes. When it does see a change, it then programatticaly fires off the appropriate event case in the parent via the control's 'Value (Signaling)' property. In this way I can program normally as if events work and just plop down this introspective VI in any VI that needs to interact with the 3rd party program.
I've actually tested the abolve solution and it DOES work but there is a problem. I cannot guarantee that the FP controls will ONLY be changed via the 3rd party application, I must account for the case where somebody changes the FP controls via LabVIEW. In that situation I end up getting two events firing: one from LabVIEW (as that now works since it was changed via the FP) and one from my introspective polling loop. I've found no good way to surpress the 2nd event because 1) I don't know which source (introspective loop or LabVIEW) will fire the event first and 2) LabVIEW provides me with no information to tell if an event fired via a click of the mouse on the FP or via the 'Value (Signaling)' property.
So i'm pretty much at a loss here. Can anybody shed some light on as to why they think events aren't firing when changed via ActiveX and can anybody think of a good way to overcome this limitation without resorting to polling?
I don't have much insight into what the source code looks like for the 3rd party app to be able to change my LabVIEW VI's control values but I did find this KB article which states the following:
Problem:
I want to use ActiveX with my LabVIEW executable to set the value of a front panel control and generate a Value Change Event, similar to using the Value (Signaling) Property in a LabVIEW VI. Is there a way to do this with ActiveX?
Solution:
While you can use ActiveX to set the value of a control on the front panel, there is no way to generate a Value Change Event by programmatically changing a control value with ActiveX.
To programmatically generate events in LabVIEW, you can generate user events when the value of the control changes. In this way, you can use ActiveX to set the value of a control and the user events can be generated as part of the executable.
So it says the solution is to generate user events "when the value of the control changes" but it doesn't offer any clue as HOW you detect the control value change. Certainly a polling loop on every control would do the trick but that is a big time code smell.
So we know there is no way for ActiveX to directly do Value Signaling, but is there a way for LabVIEW to catch ActiveX events that would change a control's value? If so, then I could just register these ActiveX events and fire off an appropriate user-event for the control that was just changed by ActiveX.
Its a very large (1MM SLOC) service-based system framework that abstracts away the connections between hardware, software and services such that any piece can be easily replaced with only minor configuration changes within the framework.
Example: You want to control a power supply's voltage output with a LabVIEW PID controller VI. You instantiate the supported power supply into the framework as well as a LabVIEW PID controller VI. The connections for inputs and outputs of the PID controller to the supply are made using the framework, not code. Changing the power supply has no effect on the LabVIEW code and vice versa, only the connections within the framework change much like an Internet router -- I've been told this has some resemblance to NI's Veristand but this predates that by quite some time.
Modifciation to the framework itself is something that I want to avoid for a number of reasons: backwards compatibility, complexity, budget to name a few.
I can tell you that when you instantiate a LabVIEW VI into the framework the framework executes a pre-written LabVIEW VI that instrospectively looks at the VI you are instantiating and asks it for all its contol and indicator names as well as determines their data types. This information is then passed back to the framework which it then uses in someway to setup the necessary ActiveX communication to be able to set and read the VI's controls & indicators.
I really appreciate you looking into this in such depth. I don't think the "Call" method is going to work because it calls the VI as a SubVI but we are instantiating top-level VI's into our framework that don't immediately return.
If so, you could create a second set of controls that only the 3rd party program touches, and hide them on the front panel, then use the method you've already found to check for changes to the hidden ones, and if a change is found you then write the new value to the visible one and fire the "alternate" user event that indicates the control was changed via ActiveX instead of a button push, so you could distinguish the difference between the two
All controls & indicators (even hidden ones) will be instantiated in our framework but I still like this idea because I have full control over which controls our framework uses. Even though I'll have the visible labview ones populated as possible controls to change in our framwork there is no harm in leaving them unused by the framework.
Thank you for your research and suggestion.
