Events in LabVIEW 6.1

[Austrian]

The event structure in LabView 6.1 is almost of no use, because it only reacts on user inputs.
As consequence it only makes sense to use them in a top level VI.
Even the argument that you can avoid polling (and safe processor time) if using the event structure is not valid, because on program events the structure does not react. Therefore you still need a state machine and if you still use the event case, you have some doubled source code for the same event and polling is still necessary.

If the event structure would react on every change (not only user actions) it would be a usefull instrument, but what's the big advantage now?

[Ben]

Hi AustrianUser,

Your points are well made.

For the purpose of monitoring what those anoying users want, the event structure has been quite usefull to me.

They are the next logical step in the evolution of the LV user interface.

Let me please try to explain why I have welocomed them.

In the old days, I would put booleans controls in a cluster to allow my user to indicate what state they want my system to be in. I would read this array, find the first set boolean and do what needed done.

In this situation, I would have to take up valuable realestate of my top level VI to handle reading the array and writing back any update that are required. The more options in the app, the more space required to handle maintaining the interface.

When control ref's came out, I was able to push all this distracting GUI stuff down into a sub-VI that was able to maintain the display and notify my code of user requests. This help make my "Top-Level" VI's exactly that, Top Level. No confusing details that distract a reader from the programs structure and and organization. The problem that I had with this appraoch was that other developers would have to take the time to read the "VI Info" for the VI that handled the user interface to learn how it worked (you know how people are about reading intructions these days).

But now with the event structure I get the best of both worlds. The code required to poll the user interface now is stuffed neatly into the "event structure" itself. This performs the functions that had been taken care of by my sub-VI (mentioned above). The second advantage is that the event structure is a LV standard! Other developers do not have to read up on my sub-VI to figure out how it works.

Another advantage is...
THe event structure is very flexible. The Sub-VI I mentioned above was rather robust. It would automatically read the labels of the controls in the cluster and when a button was pushed, return the name of the button. This name was then used to control which state of a state machine was entered next. I though is was pretty cool and used the same sub-VI in a number of projects and only had to changes the button names in a strict type def.

As flexible as this Sub-VI was, it only handled booleans. Last week-end I put together an app that not only had to watch a set of booleans but also had to monitor a picture control that was used as part of a custom control.

I right clicked, BOOM, the event structure now supported the picture control clicks!

Next, I do not have to put my booleans in a cluster any more. I can scatter these babies all over the place now.

Enough said,

Ben

[Austrian]

Hi Ben,

I got your point and I accept those advantages you have mentioned.
But I think if the event structure would react on both, user and program actions, your application would still profit the same (without disadvantage) but the flexibility would be higher and an additional advantage for programmers could be gained, right?

In a program it often doesn't matter if an action comes from the user or the program as long as the reaction is the same.

Thanks for your answer.

The event structure is a really good improvement of labview but it seems for me that not all possible advantages were achieved yet.

[Ben]

In answering a realeted question, Greg McKaskle pointed out that if the event structure reacted to program actions, you could wind up with a feede-back condition.

i.e.
User clicks
event triggers
program set controls
event fires
etc, etc, etc

This woulod be bad.

Ben

[RoboLab_Maniac]

AustrianUser,

Just remember that this is the first go around with the new Event structure. When I took the LabVIEW Advanced course, it was made clear that this new structure only reacts to user interface events and nothing else. The instructor also mentioned that they were working on other types of events as a possible addition to LabVIEW in the future. So far, I like the Event structure and have had no problems with it. However, I would agree that more things could be added to it in the future. But, for a first shot at adding this to LabVIEW, I think it was done well.

[TimTower]

Hi Ben, I enjoyed your response. However, what I am writing about concerns a statement you made "It would automatically read the labels of the controls in the cluster and when a button was pushed, return the name of the button.". I have been trying for a long time to find a way to do this (i.e. programmatically read the labels of controls or indicators in a cluster). These are not available as properties. Would you be kind enough to tell me the trick please? I would be very grateful!
Thanks Tim

[Allen Weekley]

An easy way to make a program react identically to either user or programmatic events, but still retain the advantages of the event structure (i.e. no polling loop) is to use a queue driven state machine. Add an alement to a queue in an event structure, or add it elsewhere in your program. The queue driven state machine will not know the difference. The program can have exactly the same reaction to a user event as a programmatic event, if this is what you require.

[Ben]

Hi TimTower,

In LV 6.X;

Get a reference to the cluster control.
Drop a property node and select "[Controls]". THis will give you an array of refs to the controls.
Wire this to a for loop and drop another property node inside it and select "Label".

Let me know if you need more assistance.

Ben

[TimTower]

Hi Ben, I tried this, but the resulting lable array contains "Ctl Refnum 2" for each control's label. See attached "ExtractCtlNamesFromCluster.vi". What am I doing wrong?
Thanks Tim

[Ben]

I am much better with visual aids.

See attached.

Ben