User Event

[AristosQueue (NI)]

I've flagged the tech writers to take a look at your document so they can consider revisions for future LV versions. Thanks for hanging with us through that discussion. I hope you've got enough to proceed with programming your VIs.

[wildcatherder]

Thank you for your repeated replies in assistance.  I have cancelled the technical support ticket on this subject.

[vitoi]

I like to programmatically fire off events and found the whole process of Create User Event, Register Event, Unregister Event and Destroy User Event and making all the required connections all too much considering there is a much simpler way of programmatically firing an event. (By the way, calling them User Events is a misnomer since they are not "user" events (front panel clicks), but rather the opposite, namely programmatically generated events!).

So, what's the simpler method I hear you ask?

Being a RISP (Reduced Instruction Set Person), I like to use a small set of operations to perform my tasks. Here is the method:

1) Create a Boolean indicator and place this indicator out of sight (I put it on a "developer" tab on my application, but anything will do)

2) When you want to programmatically fire an event, just create a property node of Value(Signaling). Set it to true (not necessary, but you get a bonus effect).

That's it. How difficult is that?

When you want to create an event case to handle the event, just add it to your event case structure using the indicator’s name: Value Change. Put the terminal in the event case, setting it to false (not necessary, but has a nice benefit which I'll explain later) and make the terminal the last thing to execute (I use a sequence structure).

Not only is this simple, but there are a couple of interesting by-products.

1) If you want to quickly go to the event case that handles the event in question just go to the "developer" tab and double click the indicator

2) By looking at the "developer" tab you can see which events are firing and ... if the program hangs, which event handler things are stuck in. The relative intensities also tell you how often hey are called.

I really like this ease of access and visibility.

Of course, you may want to pass a value to your event handler, in which there are several simple methods, but I prefer to use queues. (Simplest would be to use a non-Boolean indicator, but I rarely need to pass values – just trigger an event – and I find queues useful as I can queue a whole bunch of data a process it periodically.)

I've used this mechanism in large applications and it works a treat.

The purists will say this is all wrong, but pause to think. This is an easy to understand, easy to implement and effective method of programmatically generating events.

I’ve reproduced the previous VI’s function below to show the difference: