Jump to content

Suppose we limited 1 event structure per block diagram?

Recommended Posts

The only time I might be tempted to use 2 ES is when I want to split out UI events and control reference event registration.  More specifically, when registering control references, you have to deal with the issue where you are not allowed to register when the FP is closed.  (See related post here).  I like to isolate this issue from affecting UI events and other dynamic event registrations.  

If this issue were fixed, I would have no objections.  I'd have to revise some legacy code, but if there are major advantages to NI for doing this, I would understand.

Link to comment
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?

Magic. Probably rubbing Aladin's lamp and getting the genie to patch up the diagram. 


Seriously, though, I've given zero thought to how I might fix stuff up in mutation. I'm trying to get a sense for whether or not its even worth brainstorming in that area or not. I'm getting a sense that it would not be viable. Pity. 


Thanks, all. Have a Happy Thanksgiving. 

Link to comment
Magic. Probably rubbing Aladin's lamp and getting the genie to patch up the diagram. 


Seriously, though, I've given zero thought to how I might fix stuff up in mutation. I'm trying to get a sense for whether or not its even worth brainstorming in that area or not. I'm getting a sense that it would not be viable. Pity. 


Thanks, all. Have a Happy Thanksgiving. 


Forgive the naive question, but would it be possible to make this an option say for a project or something?  I as a developer agree upfront to this restriction for an application and suddenly I have access to all the cool things you are hinting at, yet not break backwards compatibility?  Or if you turned it on for legacy code, existing BDs with multiple ES would show up as broken.

Link to comment
There's a lot of brainstorming going on around possible new features


What value proposition do you offer, if we agree to limit a diagram to a single Event Handler Structure?


My knee-jerk reaction is fight such a change (since, naïvely, it feels arbitrarily limiting, and perhaps for benefits that don't matter to me). But having thought about this quite a bit -- any changes that enable Events to be used more ubiquitously (including registrations for many shipping APIs, and registrations on different comm types such as Queues and Notifiers) would be welcomed.


I can dream even of defining systems like Tomi describes on his newly-revived blog ExpressionFlow, where rather than having Terminals enabling synchronous dataflow between networks of VIs, we have Incoming/Outgoing Event (Message) Definitions that enable async dataflow between nodes (VIs). Here, a 1:1 ratio between VI:Event Handler probably makes sense, to simplify routing.

Link to comment

I'm late to the party on this one, and largely unable to contribute due to being mid-vacation, but...

I understand all the arguments in this thread, and while the points you all raise are valid, I feel that if reuse, decoupling, or the like are the motivations for arguing against AQ's proposal, I'd have to say I think you may wish to reconsider.

I generally agree with the ideas you have all raised, but if you end up just slapping all these loops/structures on the same diagram to get these gains, you have just shot yourself in the foot. Put them in a sub VI, and the single ES limitation would not affect you. That subVI may well then prove reusable, will be decoupled, and open other doors that come along with being a subVI if desired (reentrancy, dynamic loading).

I like the idea. It can likely reduce mistakes many new programmers make, and for the advanced programmer I don't see it imposing any real restriction-- to the contrary I see it promoting good practice.

Link to comment
It can likely reduce mistakes many new programmers make, and for the advanced programmer I don't see it imposing any real restriction-- to the contrary I see it promoting good practice.

But does it leave a path of easy steps for new programmers to learn?  If you can only use technique X if you also use techniques Y and Z too, then you’ve introduced a high all-or-nothing step in the learning curve.  

Link to comment
and for the advanced programmer I don't see it imposing any real restriction-- to the contrary I see it promoting good practice.


Until you've lost it forever then realise, "bugger!".


AQ hasn't stated what the "return" is. It could be that it just  removes some part of an internal document that someone doesn't like.. Until I know why it is being considered and what the gain is. (and the caveats), my default position is "anti" as I am with any removal of working features without good reason - especially if they have been around for many years.

Link to comment

I find the whole 'put it in a subVI' argument to be less than compelling here.  There is only a tiny distinction between code on a BD and code swept under the rug and into a subVI, and with inlining there is even less of a distinction. 


But let's pretend I agreed with the notion that one event structure is better anyway.  Do I really want a feature in LV built on the foundation which requires this artificial limitation?  Especially one of the core features? 


On the bright side if they do this then AQ is the proven master of the "we restricted the syntax to do you a favor" spin and can write the white paper.

Link to comment

Well yes, it is a weird restriction. I can't think of any language which restricts say one "switch" construct per function call or the like. Flip side to that though is you can see it in languages like the C flavors where functions can't be nested, whereas in other languages like javascript you can.

Also agreed on that if there's no good reason to take it away, I don't think it should be. There is a smell to the proposal I can't place.

I'm just saying that it wouldn't affect me personally, and don't really buy in to a lot of the arguments presented here, except breaking existing code.

Link to comment

A VI is both beautifully and grossly overloaded to be many things.


Give it a conpane and inputs/outputs -- bam, a VI is a function.


Give it a loop -- bam, it becomes a process.


Give it some outbound messaging transport mechanisms -- bam, active object.


Give it an Event Handler Structure -- Bam. Actor. (To be fair, a VI is an actor all along... down to even the Space Constant... just many levels of pared-down actors)


Now, start composing each of those roles into collections -- you get APIs, then libraries, then systems, then applications. Each of these levels of VI definition and collections of VIs requires different semantics and programming styles.


I see the limitation of one Event Handler Structure per VI as a decision that has the potential to significantly improve our abilities to build the higher-level abstractions in LabVIEW that are currently laborious and suboptimal. For instance, this opens up new possibilities to expanding the API of VI Reference instances -- we can start to drop existing primitives (like Generate Event) onto a VI Reference, since that VI has defined itself as being able to handle a set of messages that it can receive, and could even declare types. Imagine: a VI could declare its asynchronous API (rather than having to manually route the plumbing yourself as a dev -- we rise from procedural definitions of behavior to declarative definitions. Though, perhaps this declarative definition is stored at the LVClass level and then routed to a handler process within the class? We can skin the cat a few ways; different syntax, same semantics.)


Singletons, single instances of APIs or syntax -- those can be limiting or even crippling -- but right now I don't feel this proposal falls into this category. Now, if we were talking about only allowing one Event Registration wire (this one: post-17237-0-47132200-1386113552.png) -- I'd fight this tooth and nail, since it destroys semantics of a thoughtfully-designed active object in LabVIEW. (Spoiler: this wire and the Register For Events node, contrary to popular belief, absolutely have an N:1 relationship with any arbitrary Event Handler Structure)


The Events API is perhaps my favorite API in the entire LabVIEW language -- syntax is gorgeous (five nodes and structure) and semantics are even better. Event-driven programming is the backbone of anything I create. Those of you who saw my NIWeek 2013 presentation are aware how excited i get on this topic! :-] I say this, just to emphasize good faith and optimism that even though we're discussing a restriction, what we're really talking about is bounding the bigger picture that could enable much cooler things.

As with the other comments above, I'd be disappointed if this proposal is meant just to weld on the training wheels, yet incredibly excited if it's to enable better syntax and VI definitions for building systems. I'm just curious for OP to reveal a larger surface area of his genius and roadmap than a simple, controversial question.  :)

  • Like 2
Link to comment



I can agree with all of your statements, esp the last one about what's the real objective, what's the vision of imposing this restriction.  If it's training wheels (which is my fear) then I'm definitely opposed.  If on the other hand a carefully crafted and developed approach implementing what you've described would be simply amazing and wonderful.  I guess I'm from Missouri on this one: I want NI to "Show Me".

Link to comment

Jack, the problem is that you're building a structure on assumptions. AQ asked if people do this (yes) and if it would hurt if it was gone (yes, if only because of backward compatibility).


Unless AQ tells us what these wonderful new features are, we have no way of weighing the pain/gain ratio ourselves and I have no intention of playing a guessing game. As far as I'm concerned, if NI wants to have an implicit VI-event structure connection as you suggested, it can implement this by having a right click option on the event structure to say "this is the one event structure, forged by Craig in the fires of the R&D department" and only allowing one event structure in a VI to have this option. I have no idea if this is a reasonable solution, but that's up to NI to say.

Link to comment

I was off on vacation. But I got the info I needed -- this is a used feature so don't muck with it.


Thanks, all.

Oh. I just saw the raft of posts asking why I'm asking this. It's mostly so I know where the bounds of brainstorming are when trying to improve communication systems. I've always thought it was kind of dumb that we enabled multiple event structures within one VI because of the static registration of events, and it was just one more axis I have to worry about if I do anything in that area. I can't answer the question "what would we be getting in return" because I'm not sure -- I don't have a firm proposal at this time. I needed to know if it had intrinsic value at all because it simply does not in any programming I've done. Indeed, my first instinct when I've seen code that does this is to say, "I'm guessing your bug is here, and I bet it gets fixed if we refactor to remove that second event structure." Y'all highlighted some reasons why you like it. I'll keep those in mind.

  • Like 1
Link to comment

The true LV ninja would look at the code and determine the specific cause of the bug. 


It typically involves duplicating events, improper FP locking, or the #$%@#$% bug that unhandled dynamic events still reset the timeout.  If only there were a tool that analyzed my VIs for these kinds of bugs...

Link to comment
 the #$%@#$% bug that unhandled dynamic events still reset the timeout. 

Check your upgrade notes. Page 11.



As for the rest...

The true LV ninja would look at the code and determine the specific cause of the bug. 

Two event structures generally indicates the user I'm working with doesn't understand what an event is nor do they have any sense of their own code's operation. That, more than any particular coding error, is the source of the bug. There's no reason to bother fixing the specific issues you describe (FP locking, duplicating events, etc) when the bug is architectural. The advanced users that have posted here are describing cases that sound reasonable, but I have never seen them used in practice. 

Link to comment

I was thinking about it and I wonder if when LabVIEW first introduced event structures, if people had one event structure for each control.  Certainly not knowing the intended way to work with a tool is a common way to use it improperly, and generally speaking having multiple event structures is a red flag for this.  But when advanced users know what they are doing, powerful things can be done with these tools.

Link to comment

I agree with that: "...when advanced users know what they are doing, powerful things can be done with these tools."  Yes, they can be misused by those who don't know what they're doing, just like an FGV can devolve into what I call a DGV (DYSfunctional Global Variables) by not making them An "Action Engine".  But that doesn't mean to me that NI should somehow preclude the use of them.


In general without knowing the actual benefits of such a restriction it really doesn't make much sense to me.  Far easier to say: Use more than one Event Structure with great care and attention.

Link to comment

I would say that almost all of the time it's POSSIBLE to do what I do without using multiple event structures in a single VI.  But if the workaround (automatic upgrade path) is to simply plop each extra structure in a sub-VI (and perhaps inline it) then what advantage is the change actually going to bring?  It seems like an optimisation which could cause more problems than it brings but IF it brings some magical properties, then I'd be all for discussing it.  I'm the last person who thinks that backward compatibility needs to be maintained at all costs.  I feel there are many big changes which could benefit LV but I don't have the insight into the inner workings to guesstimate whether this would be worth it or not.

Link to comment
  • 9 months later...

Sorry about reviving such an old thread. but I noticed David Boyd never got an answer to his question about where the recommendation to have only a single Event Structure on a block diagram came from. It came from the fact that LabVIEW registers the static UI events in a VI's ES'es at VI load time. This means that if you have the same UI event configured in two event structures on a BD, those two ES'es will register the same event refnum basically, even if these two event structures do not run at the same time. Same as forking the event registration refnum - a very bad idea.


For user events, no problem with multiple ES'es per VI (bad design perhaps). For UI events, be very careful not to trigger an event in an inactive ES (i.e. don't trigger an event in an ES that sits in a currently inactive part of your code)! I guess this is the bug-hole AQ and NI wants to get rid of?


Anyways, while I'm here, I sometimes use multiple ES'es on a single BD. Rarely for user events (those get put into subVIs typically, since they can), but actually for UI events (and I am really careful doing this, and it's not very often). It happens on those occasions where I have a really simple state machine that steps through a tab strip for instance (more or less one state per tab). In that case it's convenient to register each tab's controls in each their own ES, and activate each one of those ES'es in each their own state of the state machine (usually the ES'es sit in cases in a case structure with a loop around it, you know?). What must not happen in this configuration is statically registering for a UI event that can be triggered from several tabs. You can't (manually) trigger a Value Change event on a control located on another tab than the one you're looking at right now, but you would be able to trigger a Key Down event for instance... Just saying, be careful.




Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use.