(If this is not the right forum, please move as appropriate)
Yesterday, I was trying to capture the "key down?" event on a string array control. I noticed that the event would never get fired while typing into one of the strings in the array. The event does fire if you type in the index control of the array. My question: Is this expected behavior or a bug? After trying a few things, I can get the behavior I want by getting a reference to the "ArrElem" and registering it for the "key down?" event and passing the into the dynamic event terminal. This is fine for my purposes and will implement my code in this fashion. However, I certainly was not expecting this event to behave in this way. I guess I could see why this may be the case (you are typing into a string control, not an array) but curious what other people think...
This was all done in LV2013.
By Sean Donner
We have a 3rd party application that can talk to an arbitrary LabVIEW VI (or exe) via ActiveX and can both change and read the controls on the VI (or exe). The problem we are facing is that the ActiveX interface does not support events. This means that if a control registered for a value-change event has its value changed over ActiveX the VI does *not* fire off the value-change event; although the control's value will indeed change.
Currently, our developers are working around this issue by forgoing the event structure altogher and using a polling loop instead. My goal is to see if I can abstract away the polling loop so the developers can use the event structure and I'm *almost* there but I've hit a problem. I've abstracted the polling loop into a "brat" VI that gets a ref to the parent and uses VI server to do the polling and if a value is found to be changed it issues a value-signaling event via the control's property node.
This solution works exactly how I want it to as long as the *only* thing doing the value changing is the 3rd party application. The problem lies in the fact that the VI's front panel is still required to be visible and operational such that a user can change the control via the front panel as you normally do. If a user changes a control via the front panel, not only does my "brat" code detect this change and fire off a value signaling event but because it's done through the front panel the event structure fires off as well and now I get two events firing when I only want one.
I don't expect there to be an elegant way to solve this, but what would be the least ugly way to do it? Is there anyway for my "brat" code to programatically detect the last time a control ref had an event fired, *and how* (front panel vs value signaling)?
I am receiving encoder position values from a DAQ Assistant. After either of the positions DTP or NGTP are greater than a particular value I need to fire an event. The problem is the while loop to acquire the position from the encoders is running in parallel with the main while loop for all the events. This is to enable constant updation of the position values. Below attached, is a diagram of the DAQ Assitant while loop.
I tried creating an indicator and used value signalling but it did not work. I also tried using a control (button), but with the parallel loops it doesnt fire the required event. I changed it so that I have the event loop for the button inside the encoder while loop, but that just froze the while loop. I could not see any change in the position information from the encoders even when the drive was moving (information received from the drive via Profibus : this is running in a parallel while loop).
Any ideas as to how to solve this?
Below I have also attached the code for the main panel.
I hope you can help me with my problem.
The problem that I want to solve (in a proper way) is the following:
I have a list of all the *.dat files in a folder. I want this list to update every time a new *.dat file i created in that folder.
I don't want to pool the folder constantly so I have solved this problem by using a dynamic event from a .NET action. This is all nice and great.
My problem is, that if I change the folder, my dynamic event does not execute when a new file is added to the new folder.
I have attached two snippets of the main part of the code.
In the mainVI, I first setup some events. The events are then written to a global variable. It is this global that I use when broadcasting the event.
In the watch_dir.VI the .NET event is setup. I look for files that are created, deleted, changed or renamed. (Most of the code is from Steve Chandler's nugget: http://forums.ni.com/t5/LabVIEW/My-First-Nugget-Directory-Changed-Event/m-p/1407552)
I have tried initializing the different events when the folder is changed,but that does not seem to fix the problem. I hope I have made myself clear, but please dont hesitate in asking questions.
I could off course just pool the number of files in the folder or something like that, but that doesn't seem right to me.
I hope you can help me.
New Events features in LabVIEW 2013 (Flush Queue, High Priority Events, Event Inspector Window, etc)By Michael Aivaliotis
I did a presentation at NIWeek 2013 on the new user event features in LabVIEW 2013. I will post a link here when it's ready for online consumption. For now, I'd like to start a discussion on what all the LAVA members think of the changes and additions. If you have questions on how one feature or another work, please post here and we'll get it answered.
To summarize, here is what was changed, added:
New - Event Inspector Window (you're gonna love this!) New - High Priority events New - Flush Event Queue Function New - VI Scripting methods and properties for events New - Mouse Scroll Wheel Event Improvements to the Edit Events Dialog: It's now resizable (Finally) You can filter search the list of event sources and events. For easy navigation. You can limit instances of the event in the static queue (Similar to Flush Queue function)
[*]Finally, there was a behaviour change: Non-handled, dynamically registered events do not reset the Event structure timeout terminal. In LabVIEW 2012 and older: Non-handled, dynamically registered events reset the Event structure timeout terminal.
Let's keep this positive. We all need to learn how to use these new features and how to integrate them within our frameworks. I know a lot of you are using user events as the main communication mechanism for your processes and modules. Let's figure out how to make our code better with all this new cool stuff.