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

[X.]

1) I am just saying that you could go around your request with a common case in your consumer loop: when you pass your event parameters, instead of going to a specific case directly, it goes through a common case (dispatcher) that adds one or two events to the queue depending on what you want to do (handle the event after a common part or right away).

2) A few I have reported:

Rejuvenate the Rearrange Case window of the Event Structure

Weird bug in Event Structure

Another LabVIEW bug Event Structure Pull down List does not show

Event Structure Bug Changing the type of a Numeric is not

During last beta, I was lambasted by a developer because I was pointing out that you can not multiple select events in the Event Specifier list (nor can you rearrange them). They fixed the missing "Delete" shortcut though...

So if you consider all these basic PRODUCTIVITY issues (things that hurt you everyday over and over again) versus your quite specific and easily addressable otherwise suggestion, I am  voting for the productivity issues being fixed first.

But that's just my opinon. 

[Andreas_Pfichner]

Hi X,

now I have got you! I like your suggestion better than my suggestion with the eventstructure!

Thanks and regards

[Intaris]

Wait a minute.  The event loop is not always a producer loop.  In many of my designs it's actually the consumer loop so the solution you are mentioning with the common code in the consumer loop won't do anything for me personally.

[Andreas_Pfichner]

@Intaris: I understand - and I still think it would be nice to have that feature. However - there is a workaround and I like the workaround with the consumer loop better, because in general I use consumer loops anyway...

With best regards

[Intaris]

Just in case anyone wants to go and start revoking kudos.....

[X.]

Isn't there a kudo black market somewhere on this site?

[Andreas_Pfichner]

@Intaris and X: Thank you very much for your very meaningful comments ...

[X.]

@Andreas_Pfichner: You're welcome. Just make sure, in your dispatcher case, that you put your queue elements at the beginning of the queue, not at the end...

[Manzolli]

There is a primary difference applying a Producer/Consumer architecture that will not work properly in some cases. In the idea proposed here, the actions will be executed right away, after the event. Using a Producer/Consumer architecture may produce some delays, like when the Consumer get a big task to do and get stuck there for a while.

A typical case is when you have a user interface that for every user action (button press) you want to activate a feedback (sound, vibration, light, etc.). The feedback should be right away after a button press, or the user may press it couple times before he receive the proper feedback.

Agree that the after frame is not necessary, but nice to have it.

I would like also to have a Boolean input to in both before and after frames to activate and deactivate, have True/False cases or even an Enum to allow many cases. This would give some extra flexibility to this new frames.

[X.]

@Manzolli: XControls would do the job for you (if we are not talking about a zillion different types of inputs).

Disclaimer: I will not fight this battle. If the feature is implemented, you will know who to blame. I have names...