Multiple event structures in one program

[guangdew1]

I know it's not good practice to have one event structure inside another event structure (I don't know exactly why). But if another event structure is in the subvi, is it safe? Please comment.

[Muthuraman]

Hi,

My Opinion for not a good practive to event structure is

1. Same VI shouldnt have 2 Event structure in parallel - Reason : We cant predict which event structure has captured the event and which havent. More over it is not good for processing also.

2. One event structure shouldnt be placed inside another Event structure directly : This DOESNT make sense because one event structure is always above to handle as much event as possible. Moreover the labview application is getting complex.

But placing a subVI (which has event strucutre) inside a event structure is totally accepted provided you make sure of 2 things.

                                       1. The master event structure (and ofcoarse its UI) waits until the Sub VI event structure completes and exits - Eg. Authentication module or a custom dialog box.

                                       2. If the master event structure shouldnt wait while the SubVI event structure runs - Then synchronisation has to be handled properly.

So, my simple answer is YES, WE CAN BUT WITH *-CONDITIONS APPLY.

Did i answer your question

Regards,

Muthuraman 

[altenbach]

---

@guangdew1 wrote:

I know it's not good practice to have one event structure inside another event structure (I don't know exactly why).

---

This is because of dataflow and the way event structures work. If you have an event structure inside an event structure, both event structures will accumulate events whenever one occurs, but it is unlikely that they can be handled in the order they occur or at all. By default, event structure are set to lock the front panel until the event completes, meaning that if an inner event gets triggered first, the code will lock up, because it will no longer be possible to trigger one of the outer events. If the outer event occurs first, it cannot complete, because it requires a later firing of one of the inner events before it is ready to handle the next event that occurs in the UI. Even if it marginally works if the panels don't get locked, you are requiring the user to trigger events in a certain order. How is he supposed to know what's allowed or not?

If this is not exactly clear to you, you need to start with a few tutorial and learn about dataflow, Then start using a single event structure and see how things work by programming scenarios and see what happens.

---

@guangdew1 wrote:

But if another event structure is in the subvi, is it safe? Please comment.

---

Event structures are only useful inside interactive subVIs that show their front panel. even then I strongly advise against calling anything interactive, or anything that takes excessively long, inside a main event structure. You end up with code that can become unpredictable, can deadlock, is hard to debug and flies in the face of all good programming guidelines.

Obviously, you have some specific application in mind where you think something like that is useful, I can guarantee you that there is a much better solution is you think about this a bit longer. If you need help, please describe exactly what the program should do and how it should react to user interactions at the various stages.

A program should always be approached from the code and UI needs. Don't start with a harebrained code construct (events inside events) and then look for a use. It does not exist! 

Event structure only belong in toplevel loops. They should never be hidden insde squences or case structures (or other event structures as already mentioned above). If you have multiple toplevel loops that run in parallel, it is safe to place up to one event structure inside each. Each event structure can have an unlimited number of event cases. This should be sufficient to handle any programming need you might have.

[guangdew1]

Muthuraman,

Thanks for your response.

In certain cases, logically some of the actions belong to one of the main event structure case, so we may think of adding another event structure in that case. But actually, if we extend all the event and use just a flat event structure, it will handle everything okay.

[guangdew1]

altenbach,

Thank you for your response to my post and advices.

In my program, I have a event structure in the main vi and in one of the frames, it will call a subvi which is a popup window and it contains another event structure in it. Test operator does need to operator the subvi and the main vi will proceed only after the subvi is closed.

Of course I can put everything into the main vi to achieve the same functionalities, but the front panel will get too crowed. 

[altenbach]

---

guangdew1 wrote:

In my program, I have a event structure in the main vi and in one of the frames, it will call a subvi ...

---

What is a "frame"? Where is that "frame" (main vi? subVI?)

Just make sure that the subVI always completes successfully and that its front panel cannot be closed in any other way. If the operator could close the window while keeping the subVI running in the background, your entire code will lock up because there is no way to continue.

[guangdew1]

What I mean is an event case. I will make sure the subvi has to be executed and closed properly then the main vi will continue.

[billko]

---

@guangdew1 wrote:

What I mean is an event case. I will make sure the subvi has to be executed and closed properly then the main vi will continue.

---

I don't like to have more than one event case in a VI.  Instead, I would place the second event structure inside a sub VI configured as a dialog box and have the results as a sub VI output to be acted upon by the main VI.

[JÞB]

---

@billko wrote:

---

@guangdew1 wrote:

What I mean is an event case. I will make sure the subvi has to be executed and closed properly then the main vi will continue.

---

I don't like to have more than one event case in a VI.  Instead, I would place the second event structure inside a sub VI configured as a dialog box and have the results as a sub VI output to be acted upon by the main VI.

---

And this is exactly the one use case where it is possibly useful "The user wants to change something that the main app needs so the top level MUST pause until the user decides a new course of action."  This should only be attempted though when the whole application IS paused (no little deamons doing anything else that feeds the UI) so this approach is NOT really scaleble up to large applications.

[billko]

---

@JÞB wrote:

---

@billko wrote:

---

@guangdew1 wrote:

What I mean is an event case. I will make sure the subvi has to be executed and closed properly then the main vi will continue.

---

I don't like to have more than one event case in a VI.  Instead, I would place the second event structure inside a sub VI configured as a dialog box and have the results as a sub VI output to be acted upon by the main VI.

---

And this is exactly the one use case where it is possibly useful "The user wants to change something that the main app needs so the top level MUST pause until the user decides a new course of action."  This should only be attempted though when the whole application IS paused (no little deamons doing anything else that feeds the UI) so this approach is NOT really scaleble up to large applications.

---

I hate that my brain was configured with only an 8k I/O buffer.  By the time I got to the bottom, guangdew1's second reply was overwritten.  😞