Add First Run event on event structure

[Eric_BOB]

if you want do something from the start of event structure, you can creat a dynamique registration event a fire it immediatelly ,like in diagram below.

It will be  handy to put on it the initialisation actions and like that minimise the size of diagram.

I like if there is one even "first run" on even structure (first run or first iteration).

Eric

[PhillipBrooks]

I often use the timeout case for what your call 'First Run'.

I compare the iteration count to zero, if true I pass zero to the timeout terminal, otherwise I pass -1 (no timeout). This logic could be easily turned into a user.lib library VI.

[AristosQueue (NI)]

This shouldn't be needed... can you explain more about your use case?

[TCPlomp]

Well it makes the usability of an event driven state machine a bit more versatile (but I guess that if you have a event driven state machine, there is allready a 'generic user event'.

But why not.

It sounds like the XControl 'Execution State Changed Event'.

Ton

[K C]

When I use a event structure and want to initialize something on first run I use this solution. It also gives me an option to reuse the Init event when necessary.

[Eric_BOB]

I agree with aristo and KC , we can do that with their solutions. But with my proposition we obtein a more clean diagram (i think).

It's the only reason of my proposition.

[altenbach]

I suggested that before long ago, but I cannot find the post.

(Here's another old related discussion. It uses a shift register instead of a comparison+select to trigger the timeout once. Probably a bit cleaner that Philip's version above).

> This shouldn't be needed... can you explain more about your use case?

Aristos: often the first run code is identical to the code in one of the events, so duplicating the code into a sequence is not very efficient. Why do we need to code the same twice? If we change something, we need to edit it in two places, possibly leading to errors and oversights.

One reason we need to do something like that is to bring indicators  in sync with the current control values. The controls might have changed at edit time. The indicators might contain only default values. We don't want to save an application with all indicators containing default values (e.g. a graph with a simulated spectrum based on all controls), they can be calculated once at the start of the program and recalcuated when the controls change. It is annoying if a program is started and the indicators contain stale values until a control is operated.

Personally, I don't see the need for this any more. Usually one of the following three solutions is appropriate:

(1) In simple cases I use the timeout and a shift register as in the above link (see picture, top).

(2) In more complicated cases, I line up signaling events to trigger all events that need to run once at program start (bottom). In most of my more advanced programs, I need to trigger several events anyway, so this suggestion would not help. The signaling nodes also allow me to easily set defaults via diagram constants and I don't need to remember to save with changed default values whenever I want something else.

(3) Most of the time, my display data is contained in shift registers. Placing the indicators before the event structure makes sure they contain defined values and not some leftover from a previous run (not shown). 

[seVEMes]

I like this Idea. I came to create it on the idea exchange but it already existed here. The work-arounds that I found here will do for my case but having it implemented would be much cleaner.

Vince M

[TimsTools]

The above solutions assume that the "Timeout" and the programmers First Run are the same event.  They may not be.  I have cases where some of my events I want to run First Run are not the Timeout, but need run at least once.  I would really like an "Application", "First Run" Event in the event structure selections that I could assign to any event frame.

SpaceGuy

[AristosQueue (NI)]

First, I need some clarification: What does this event case mean when the VI is called as a subVI? Suppose I have a dialog VI. It will be called multiple times during the run of my top-level VI. Some of the examples posted, including the workaround from Altenbach, would run every time the VI is called. Other examples posted, including the example from K C, would run only on first call -- aka, once per run of the top-level VI. Which one is the desired behavior? My guess is that you want both, but I want to know.

Second, I see a problem with implementation: What is the behavior of this event structure if an event it is dynamically registering for has already happened before the event structure executes the first time? Given that events are handled in the order they are generated, if this is an event that is regenerated when the VI is called, we would have the possibility of dynamically registered events being handled before this event is handled.

For the record, this kind of race condition could be a problem with Altenbach's Timeout workaround if any dynamic event registration was involved. Events could already be in the queue, so the zero timeout wouldn't happen.

Third, I hope this feature never happens: As a member of LV R&D, I try most of the time to help you guys clarify your desires and make this the best idea possible. But sometimes, I need to take off my R&D hat and just speak as a user of LabVIEW. This is one of those times... and I'm asking... please don't code like this.

Consider this diagram:

This stacked sequence is effectively exactly what you're asking for. You want code that needs to run before some other piece of code to be stacked up, to preserve diagram real estate. <Insert all arguments against the stacked sequence structure here.> In the stacked sequence, if you have any data that you generate in your initialization frame and want to share with your other frames, you can use a sequence local. You'll have to use a shift register for that purpose with this new event, but it reads the same.

You've added another frame to flip through in the event structure, one that is never of interest when debugging after it finishes. Better, IMHO, to put that code off to the side.

The only argument that buys any weight with me at all is "sometimes the work done at initialization is something you need to repeat later in another event." That's a reasonable argument, but it is why we have subVIs. True, the interaction with controls may not be as clean if you have to pass a control reference into a subVI. I'd rather work on that problem (there's been some intriguing discussion across the forums about a subVI that is statically tied to the controls of its caller VI) than this one, which seems to me to be treating the symptom, not the disease.

In the meantime, there's a better workaround for the case where you sometimes need to repeat your initialzation code. It's essentially the "state machine with event frame" pattern.Something like this:

This one avoids any confusion about the timing of event generation.

[KeithTK]

@ Aristos Queue

"You've added another frame to flip through in the event structure, one that is never of interest when debugging after it finishes. Better, IMHO, to put that code off to the side."

I have to disagree about putting code that is "never of interest" to the side of the event structure.  If I am not interested in it, I would rather have it hidden as a case in the event structure than taking up valuable real estate on my BD, IMHO.

Adding the option to use a first-run event doesn't prevent you from doing things any of the ways you listed, and makes things easier for those who have common code between first-run and other events, so why not offer it as a solution?