Suppose we limited 1 event structure per block diagram?

[Aristos Queue]

So, you have an event structure in a loop. It's handling your UI events.

 

In theory, you can have multiple event loops on the same block diagram. In practice, I've never seen anyone actually do this.

 

Do people do this? How bad would it hurt if we said, "Nope... you can only have one event structure per VI." ?

 

I am not saying we're going to make this change. There's a lot of brainstorming going on around possible new features and that aspect of events is causing some difficulties, and I want to know how much flexibility we have to play with the design.

[Tim_S]

I've had two event structures on the same diagram, though I can't say this is common for me. It's a nice way to create a producer-consumer where the consumer needs to accept different data messages; I'm not a fan of using a cluster of enum and variant as I've been burned by all of the enum constants resetting to the default value one too many times. The other situation I've used it is when the second loop can be stopped by a button press on the front panel.

[todd]

I've used one ES for UI, and another for dynamic events. But I usually push the dynamic ES down to a subVI.

[Darin]

There are many situations where I like to have unrelated events handled by separate event structures.  Sometimes it is user events and app generated events.  Often it starts out with mulitple event loops and eventually it morphs into multiple subVIs.

 

Part of the reason I like to keep them compartmentalized is that Event Structures are like bear traps for code since until LV13 they resisted most efforts of scripting-based automation.  At least having smaller structures made it easier to reuse code.

 

Another reason they get multiplexed is that maintaining state for one event case meant stringing a wire across every other case, or doing some bundle/unbundle or LVOOP craziness.  It is much nicer to have a class/typedef cluster for state data which is logically related to the events in an event loop as opposed to a hodgepodge based on the combination of events contained in a given loop.

 

This idea would improve things a lot if we got stuck with one event structure:

 

http://forums.ni.com/t5/LabVIEW-Idea-Exchange/An-output-terminal-for-feedback-nodes-that-mirrors-the/idi-p/927458

 

Now local state can be kept local and I will have fewer wires in a monolithic event structure.

 

Bottom Line:  I see no fundamental reason to limit things to one ES per BD.  It smells like one of those easy-way-outs that may solve one problem but may add more than that it return.  I'd need some convincing that the problems of code mutation to avoid breaking code, or that the problems of breaking old code are worse than the current difficulties.

Edited November 25, 2013 by Darin

[GregSands]

I have used multiple event loops on one occasion, certainly not regularly.  The main reason for doing so was that the VI had several separate groups of controls ("components") which were largely independent, and at the time it made sense to have separate event loops to handle each component, simply for ease of programming and keeping the handling of related controls together.

 

But I wouldn't be too concerned not to have that option, especially if there were a bunch of other improvements, such as being able to group events in some way (otherwise I can have an Event menu which is several screens tall), or to import/export/merge event handling functions.  Or if adding a control (or group of controls) to the FP could also add a set of "default" events to manage those controls, which would be kind of like using an XControl, but without needing to create it (and handle all the workarounds needed to use it).  

[David Boyd]

Somewhere in the dawn of the ES (6.1? I think), while wrapping my head around this great new paradigm, I took it as a commandment that THOU SHALT HAVE NO MORE THAN ONE EVENT STRUCTURE PER DIAGRAM.  I've frequently been appalled by the code of some of my coworkers who blithely put down 2, 3, or 4 ESes in separate loops.  (Heck, I don't even like to have more than one ES in an entire execution hierarchy, maybe I'm carrying it too far?.)

 

So it wouldn't bother me.  But I am curious, AQ, if you went ahead with this enforced limitation, what kind of upgrade mutation could possibly save such (IMHO, barely maintainable) code that's out there?

 

Dave

[Darin]

Somewhere in the dawn of the ES (6.1? I think), while wrapping my head around this great new paradigm, I took it as a commandment that THOU SHALT HAVE NO MORE THAN ONE EVENT STRUCTURE PER DIAGRAM.  I've frequently been appalled by the code of some of my coworkers who blithely put down 2, 3, or 4 ESes in separate loops.  (Heck, I don't even like to have more than one ES in an entire execution hierarchy, maybe I'm carrying it too far?.)

 

So it wouldn't bother me.  But I am curious, AQ, if you went ahead with this enforced limitation, what kind of upgrade mutation could possibly save such (IMHO, barely maintainable) code that's out there?

 

Dave

 

A single catch-all Event structure is a recipe for increasing the coupling and decreasing the cohesion of your code, we must have different metrics for maintainability and readability.  That is a double-whammy in my world.

 

I have my own icon editor which has been a systematic refactoring of the shipping version.  Step 1 was converting the single ES to a group corresponding to the different tabs.  Now tabs can come and go as I please.  You may prefer to get slapped in the face when you click on the Event selector label, I say no thanks.

 

And the timeout is so much more useful with a restricted set of events.  I can have multiple time scales very easily.

[todd]

Reusable code is the way to go. Here's a meager example:

[drjdpowell]

Though recently all my multiple event structures have been in separate VIs (often with front panels assembled via subpanels), I don’t see any reason why multiple ES shouldn’t be on one block diagram.  And I certainly had such on multiple occasions in the past.

[Neil Pate]

I add a vote to not taking this feature away.

 

Like others have said, I sometimes use a separate Event Structure for User Events that can then be packaged away into a sub-VI.

[MartinPeeker]

I use multiple ES in the same block diagram, typically a similar situations others have mentioned. I let my system update running graphs and indicators with user events which is handled i one ES, UI interaction is handled by another ES that also checks system status in its timeout case. I even have ES i other parallel loops such as a clock loop, just to listen to a 'Quit' user event.

[LogMAN]

Reading all the posts, it seems that many people used multiple event structures on one block diagram at some point in their life. In fact I did so too, however this has either been because of bad design decisions (use Sub-VIs instead!) or because I didn't know better (wait what? ). It would be no problem for me to limit the number of event structures to one, or rather I would like to see one event registered only once in the same VI (maybe thats already limited in a more recent version than LV2011?). There have been very strange behavior in my VIs ages ago (4-5 years) as I tried to catch the same event on a prallel event structure (never got it working properly)

 

In my optionion parallel event structures are like global variables, you could use them and it might seem easier, but the maintainability gets worse and worse the more you use them and you must be very strict to the limitations of their usage. So don't use them at all!

 

The only reason I could accept so far is the one of Darin (because they are strictly seperated by their scope):

 

There are many situations where I like to have unrelated events handled by separate event structures.  Sometimes it is user events and app generated events.  Often it starts out with mulitple event loops and eventually it morphs into multiple subVIs.

 

However even this should have and has been solved in sub-VIs.

[ShaunR]

I can do without extra event structures as long as we get an event structure that we can wire TCPIP,UDP, Bluetooth and VISA refnums to.

[Yair]

I also use multiple event structures in the same BD on occasion, either for handling separate parts of the UI which are in the same VI, or for handling non-UI events. I wouldn't like it if my legacy code broke when upgrading to LV 202X when these features are introduced, but if those features are worth it, I wouldn't be broken up if I was told "you can only use these features if you have a single ES in the VI".

[hooovahh]

Nope, I've never used more then one event structure in a single VI.  That being said hearing how others use it it doesn't sound like a horrible situation as long as you know what you are doing.  There are pitfalls that new developers will likely get caught in, but I feel like there are plenty of places that LabVIEW allows you to shoot your self in the foot.  So while it wouldn't affect my development at the moment, put my vote to "This should probably just stay the way it is"

[shoneill]

Limiting to a single event structure would break so much of my code I'd be seriously tempted to start learning C++ again.......

 

I'm not exaggerating.

[David Boyd]

OK, having heard from all my multiple-ES LAVA colleagues, I'm seriously in need of a reality check.

 

AQ: do you recall any early caveats from NI (either in release notes, or help, tutorials, online discussion, etc.) that warned against the practice?  I'm vaguely recalling there was an issue with the way ESes invoked some behind-the-scenes setup as soon as the VI was loaded into memory, well before user code started executing.

 

Or maybe I was living in some alternate reality back in the 6.1 days?

 

Dave

[PaulL]

I'm not aware of any code I have that uses two event structures.  I do occasionally have two loops, one of which includes an event structure, and another that generates "interrupt events" that the event structure handles.  Most often (but not always) at least one of these is in a subVI.  So, on the first take, it would be plausible from my point of view to impose a limit of one event structure per block diagram, but it seems there would need to be a very compelling reason to impose such a restriction.

[Yair]

AQ: do you recall any early caveats from NI (either in release notes, or help, tutorials, online discussion, etc.) that warned against the practice?  I'm vaguely recalling there was an issue with the way ESes invoked some behind-the-scenes setup as soon as the VI was loaded into memory, well before user code started executing.

 

I don't know about NI specifically (although the caveats section in the LV help might refer to it), but I do remember people being quite forceful about it, probably due to lack of knowledge.

 

What is true (and I'm guessing those were the problems LogMAN had) is that if you use the same registration refnum for more than one structure you will get undefined and extremely annoying behavior. That's a big no-no and it's a very easy mistake to make if you're not aware of the issue. The caveats section should have some text about this.

 

In general, if you know what you're doing, you can do quite a lot. I would highly recommend watching Jack Dunaway's presentation from NIWeek 2013, as it's the most concise and understandable coverage of the various points that I've seen. You can find it here - http://lavag.org/topic/17040-niweek-2013-videos/

[todd]

Download Jack's presentation (all VIs, no powerpoint), here:

https://github.com/wirebirdlabs/LabVIEW-User-Events-Tips-Tricks-and-Sundry

"Download ZIP" button

[guentermueller]

How bad would it hurt if we said, "Nope... you can only have one event structure per VI." ?

One Event Structure per VI is the usual practice in all the code my colleagues and me produce.  There might be some VIs in our code that would break if LabVIEW came with that behaviour change.

[candidus]

In one of my projects I have multiple event structures in the main VI, but only one of them handles UI events.

The other ones are part of consumer loops that update live image views on the front panel.

and moving them into subVIs seems not to be the right option here:

I don't want to update my front panel controls via control references where performance is required...

[David Boyd]

I don't know about NI specifically (although the caveats section in the LV help might refer to it), but I do remember people being quite forceful about it, probably due to lack of knowledge.

 

I spent a little time this afternoon searching Info-LabVIEW ca. 2002, and you're absolutely right, there WAS a lot of confusion back then about how to apply the "new" paradigm effectively. IMO, more than any other feature added since I started using LabVIEW (4.0/4.1), the ES really reset the way I thought about LV programming architectures.

 

There's good lengthy discussion pertaining to the ES in those Info-LV archives, BTW, especially a few excellent posts by Greg McKaskle describing how they made the design decisions the way they did.  I'd recommend looking back through that material to anyone following this thread.

 

Dave

[Val Brown]

FWIW the word that I got early on was "ONLY ONE ES!!" so I haven't even tried to use more than one on any BD, but I have encountered situations where I really did want to do that.  The main reason was so that I didn't have one enormous ES.  And in that regard: what's with not being able to reorganize the Event States?  Or do I just not know the "trick".

 

My vote is not to remove the option for more than one ES per BD.

[soupy]

i don't think that we currently use more than one ES per BD, If we do, the secondary ES is in a subVI. Will things be broken if the subVI is inlined? (I assume it would)

 

I'm quite concerned that this breaks existing code. The LV upgrade eval process is typically riddled with surprises and this just adds another pothole. Especially since the only way to fix this is to overhaul your application architecture which isn't exactly an easy change.