Eventstructure with common code option

[Andreas_Pfichner]

Hi,

my suggestion is to make it optional within the eventstructure to execute code on each event, before the event specific code will be executed, like follows:

Please see the following example for a better understanding of my suggestion:

This option would make it possible to execute common code which is needed on every or almost every event, or to execute common code e.g. on any userevent. A filter option would be neede here to be able to filter events on which the common code should not be executed, e.g. to only use this option on userevents.

With best regards

AP

[Andreas_Pfichner]

P.S. Code example for the mentioned event filtering ...

[Intaris]

Unorthodox idea but I like it.  I'd also add the option of a case AFTER the event too.  I just don't have any actual use case yet but perhaps this is because I'm so used to the current version.....

[X.]

You should not do anything else in your event loop but pass the event and its parameters to a consumer loop handling them.

Or maybe I am misunderstanding what you are talking about. If you are talking about filtering events to avoid triggering them in some conditions, Dynamic Events are your friends...

[AristosQueue (NI)]

He's asking for "this code needs to execute inside every event frame, but I don't want to have to copy it into every event frame, but if I move it outside the event frame, then it fires long before the event occurs".

It's something I definitely would have used in two projects of mine. I wouldn't see it as commonly used, but there's really no workaround short of copying code into every event frame.

My initial reaction is that I don't like the "be able to filter the event" at that point, but I could probably be talked into it if this feature got moving and someone really pushed for it to be possible there. The reason I don't like the filtering there is that this code would only execute *when the event had already triggered the event structure to run*. In other words, if you chose to filter the event, you'd still be exiting the event structure and letting the while loop come around on its next iteration. So the event did happen, you're just skipping its core content, and that strikes me as a decision better made inside the code for that particular event -- and, indeed, in the code shown in the idea, the case structure is making a decision based on the event that is coming through. So why not just put that code in the main body of the event structure? It is cleaner and easier to remove if the event gets removed from the structure overall.

And don't forget about the filtering abilities already built into the Event Structure as of LV 2013.

I would suggest the use of the prefix (and postfix per Intaris' post) is for effects that affect all the events -- updating some "last fired" timestamp, writing to log files, locking/unlocking system resources, etc. If someone wanted to talk me into filtering, I'd need to see a lot more diagrams about what the code looks like with/without filtering in the prefix.

But I'll put my kudos on for the idea overall.

[kegghead]

Neat idea. A postfix frame would be unnecessary as this can already be done via code with a data flow dependency from the event structure. A prefix frame though, kudos.

[Andreas_Pfichner]

Thanks for your comments.

@Intaris: Like Kegghead already mentioned: A "postfix frame" is not necessary, since you are alread able to execute code for all events AFTER the eventstructure. But from the view of making things look better It would be nice to have also a "postfix" option ...

@AristosQueue: The event filtering would make it possible to exclude certain events from executing the "common code before each event". This sure will be needed, if you have that "prefix option", because there might be events on which one do not want to execute the "common prefix code". In LV2013 I do not see these features, because in LV2013 I can filter events by performing actions on the eventqueue, but then I am only able to filter the whole event ...

@Mr. X: Of course LabVIEW programmers use consumer loops to process events outside the eventstructure in general. But this is not the issue here. Taking a look on a producer-consumer architecture: I would like to avoid the following whith my suggestion: To place an enqueue function into every eventcase to start allways the same external process within a queue driven consumer loop: I would just like to place the enqueue function once in the "prefix event case" to execute that "common code" every time an event occurs, see example below. The use of the set busy function is just an example of a function which might be used for almost every eventcase - However: If you start a process (even in the consumer loop) that updates e.g. a complex list in a user interface, the set busy function is mandatory sometimes (as a userfeedback) and it makes no difference then if you put that code into the eventstructure or in the consumer loop. It depends on what your user interface should do (or to be more exact: what your customer wants the userinterface to do) and it depends on the definition of the project. By the way: I am already really a friend of dynamic events for a long time, but I have not got your point here related to the issue I am "talking about" ...

[Andreas_Pfichner]

P.S. I am not able to reedit my initial suggestion at the moment: The filter option should make it possible NOT to execute the "common code" e.g. on userevents ... If you want to execute code only if an userevent occurs you can do this already of course in the userevent case ...

[Intaris]

I would still opt for a postfix frame, not for "new abilities" reasons but for code cleanliness.  If I ever want to copy an event structure created to handle a certain number of user events, then I simply copy the event structure and I'm finished.  Otherwise we need to copy event structure plus any follwowing code.  I propose that the addition of a postfix frame (while adding nothing new to the language per se) offers a much cleaner way of organising the types of code which will be enabled by this idea.

[X.]

Looks like I got your idea all right then.

My gut objection to this addition to the Event Structure (which has so many other basic things that need improvements) is that it would potentially make it confusing (essentially you would have a separate frame that you would have to switch back and forth to in order to check what it does, etc).

No vote from me, sorry.

[Andreas_Pfichner]

Thanks again for your comments.

@Intaris: I totally agree with you.

@X: I haven´t yet got your point ... The fun thing about eventstructures or case structures is from my point of view to hide code of cases (which are not of interest in a certain moment) to make the code cleaner and clearer. - What is confusing about making code easier to read by avoiding dozens of copies of always the same code? - Which other basic things, that need improvements, do you have in mind? Are they already monitored here in the idea exchange forum (do you have a link)?

Thank you. With best regards