event structure stop

[wiebe@CARYA]

I've done this like a milion times! It's not very "pure", but how convenient would it be if the event structure itself kept looping until stopped?

This should be optional, like in the for loop ("Conditional Terminal").  For the event stucture, it wwhould be nice if wiring it is optional (unwired means keep looping), or that you can show\hide it on a per event basis.

Regards,

Wiebe.

[RavensFan]

So the event structure has a while loop integrated into it?

That means you will also need an i terminal and shift registers.

[crossrulz]

I really do not like this idea.  The event structure is meant purely for responding to events.  While Loops and FOR Loops are for looping.  Let them keep doing exactly what they were designed to do.

[wiebe@CARYA]

>I really do not like this idea.

Actually, I'm not too sure I like it... It's just an idea.

>The event structure is meant purely for responding to events. 

Exactly. But the thing is, it does not response to eventS. It is responing to ONE event... (It actually responses to more events, but only once.)

>While Loops and FOR Loops are for looping.  Let them keep doing exactly what they were designed to do.

Well, the for loop is already not pure anymore (with a conditional terminal)... I kinda agree with you. It's just that 95% of the (my) event structures have a while loop around them. The design can change, if benefits are there.

[AristosQueue (NI)]

The idea of the event structure itself being a loop was proposed as the first draft of the Event Structure. It has been discussed from time to time within R&D.

We can't make the structure always loop. We would still need a non-looping event structure. There are two cases:

1. We put the event structure inside a case structure inside a loop for the typical "state-machine-reacting-to-UI" pattern where the state machine goes into a "wait for event" state, handles one event and then go off into various other states before coming back to the "wait for event" state.
2. We also have the case where you need code inside the loop boundary executing before or (more commonly) after each event, sometimes checking other systems to decide whether the loop should exit or not.

That means we would have to make the structure very distinctive for its two modes (maybe looking like a blend of the while and event structures?). Is that cleaner to read and understand? Not sure. The Stop terminal would have to be wired in at least one frame but not all frames? To me, it gets a bit wonky combining the functionality, even though the two nodes are used commonly together.

I have seen suggestions that the palette item should always drop both and then you could delete one. What would everyone think of that?

[crossrulz]

So let's say you have several events that could stop your loop.  It is not uncommon for me to have 3 cases that could stop my UI loop (stop button value change, Panel Close, and Key Down).  So would each of these have a conditional terminal then?  That would just add to the confusion.  Plus then also adding all of the stuff Ravens mentioned: i terminal, shift registers, feedback nodes.  We're talking about a major interface change that would benefit very little.  As Stephen Mercer keeps telling us, LabVIEW R&D is surprisingly small.  Their efforts can be much better utilized on more productive ideas.

And the FOR loop is still pure.  C allows for multiple conditions in the FOR loop.  It only makes sense that we should be able to abort out of a loop prematurely.

[crossrulz]

>>I have seen suggestions that the palette item should always drop both and then you could delete one. What would everyone think of that?

I wouldn't delete the palette item.  If anything, make another one that has both (place VI contents set to true).  I could have sworn I saw that in some toolkit.  Just can't seem to find it right now.

[wiebe@CARYA]

>And the FOR loop is still pure.  C allows for multiple conditions in the FOR loop.

Who said C is pure? (Let's not make a "goto" in LabVIEW, just because it's possible in C.)

>It only makes sense that we should be able to abort out of a loop prematurely.

Yes it does. Not arguing that. It's a blessing.

I'm just saying, the design of the event structure *can* change if it's a good idea (to NI), just like the for loop changed (a little).

[wiebe@CARYA]

>It is not uncommon for me to have 3 cases that could stop my UI loop (stop button value change, Panel Close, and Key Down).  So would each of these have a conditional terminal then?  That would just add to the confusion.

Isn't the confusion exactly the same as in an event structure with a while loop? There you'd also put a boolean just in the cases that stop the loop. I'm not seeing the difference.

We'd could add the stop to the border, and make the wiring optional.

[wiebe@CARYA]

>As Stephen Mercer keeps telling us, LabVIEW R&D is surprisingly small.  Their efforts can be much better utilized on more productive ideas.

I do agree. That is a good argument.

The idea doesn't really need to include shift registers, I, N, etc, to be usefull. But for consistancy itmight be better.

I didn't post anything in a long long time, and now I'm finally using the idea exchange. I have tons of ideas. Some, like this one, might not be that good. It's still fun to talk about it.

[jcarmody]

> Exactly. But the thing is, it does not response to eventS. It is responing to ONE event... (It actually responses to more events, but only once.)

It's an Event structure, not an EventS structure 😄