Suppose we limited 1 event structure per block diagram?

[bjustice]

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.

[Aristos Queue]

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. 

[drjdpowell]

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.

Here’s the long neglected Idea Exchange entry for that very worthy idea.

[ShaunR]

Here’s the long neglected Idea Exchange entry for that very worthy idea.

 

I'm surprised people still bother with it. I did have a quick look around since you linked to it and it seems this years fruit are so low hanging they'd be classified as tubers. 

[Jordan Kuehn]

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.

[JackDunaway]

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.

[mje]

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.

[todd]

I neglected to answer the second question:

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

It wouldn't hurt much at all.

[drjdpowell]

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.  

[ShaunR]

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.

[Darin]

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.

[mje]

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.

[JackDunaway]

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: ) -- 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. 

[Val Brown]

Jack,

 

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".

[JackDunaway]

If it's training wheels (which is my fear)

 

I've got this sneaking suspicion it's not training wheels. OP is not the type to walk blindly into The Mob That Is LAVA uttering absurdities without a Pretty Good Idea to support them. :-]

[Yair]

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.

[shoneill]

Yeah, speak up AQ....

[Aristos Queue]

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.

[Darren]

"I'm guessing your bug is here, and I bet it gets fixed if we refactor to remove that second event structure."

 

I have said almost those exact words on more than one occasion.

[Darin]

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...

[Aristos Queue]

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

Check your upgrade notes. Page 11.

http://www.ni.com/pdf/manuals/371780j.pdf

 

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. 

[hooovahh]

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.

[Val Brown]

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.

[shoneill]

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.

[Steen Schmidt]

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.

 

Cheers,

Steen