How can I reduce the number of event cases in the main VI?

[Jörn]

I would like to reduce the number of event case of the event structure in my main VI. E.g. I would like to have pop up window with a table when the user double click a table row. Nothing more simple than this: add a case to the event structure trigger by double clicking the table, read the table row ... But in my main VI I would have lots of them and the event structure gets crowded with minor tasks. One solution is using XControls. But is there any other recomended way to handle selected events separatly from the event structure in the main VI?

to clarify: I don't want to distribute the whole event structure. (In this case the code would not be maintainable) But I would like to handle certain context specific events in a differnt place. If I have them all in the main VI the drop down list of the events in the event structure exceeds the windows size and the program becomes difficult to maintain because one looses the overview.

[tst]

One option for doing something like this which is simple than creating an XControl is to pass the reference to a subVI and use dynamic events to handle the events there. You can see an example here, but you should note that like any solution, it has its own set of problems.

[Norbert_B]

You can also always reading the events control like shown in the attached example..... maybe this helps in reducing the amount of different event cases.

Norbert 

[DFGray]

Are you trying to support multiple tables on the same front panel?  If so, why not have multiple events trigger the same frame of the event structure.  You can determine which table caused the event by using the control reference output of the event (check the control label).  This allows you to then use the proper handling code, although you may be able to reduce this to one piece of code, as well, depending on your requirement.

Using a single event frame allows you to encapsulate your event handling code into a single VI or small set of VIs.  I would recommend you use the event only to launch something else which handles the event.  Common options are a queue-based task handler or a dynamically-launched, free-running, top-level VI.  If you have set up your global data structures correctly, this should not be very difficult (note that using LabVIEW globals is usually not a correct method and can easily lead to race conditions, see here and here for how to do it correctly).

If this does not help, please post more details so we can help you better.

[Ben]

---

tst wrote:
One option for doing something like this which is simple than creating an XControl is to pass the reference to a subVI and use dynamic events to handle the events there. You can see an example here, but you should note that like any solution, it has its own set of problems.

---

Building Yair's reply.

See the zip I posted here under the name "docking". i that example I had sets of controls that worked together but I did not want to force the GUI to support that work so I pusehd the events strutures dwon into a template.

Have fun,

Ben

[Norbert_B]

One note to my reply above:

Reading the comment of Damien i have to point out that using popup panels in event cases is only "valid" for such quick and dirty examples. As Damien (and others) said, it is not recommended to have functions included in event cases, which can block the execution for a longer period of time.

[Jörn]

Thanks  for your posts so far. Now I have something to read...

But, Norbert, could you please post your example in LV 8.6.1

However, there is not much chances to reduce code and bundle it in by having multiple events trigger in one frame of the event structure. The tables differ too much.

[Jörn]

And I can't see why it so stricktly forbidden to have the event structure split up in a sequence like stated here.

The drawbacks are 

- If split up in a sequence I have to wíre a zero timeout to each event structure.

- I need a wait in the while loop. This causes a little processor load in contrast to a common event structure without timing out.

My advantage would be

+ clustering related events in one step of the sequence. I could put a comment stating for which group of task the events are serviced.

+ the number of events treated in the respective event structure can be kept low (about 25). Serving 100 event cases would require 4 steps in the sequence. Skimming thru 100 events in the drop down list of a common event structure is no fun.

Nesting the event structures in the steps of the sequence reduces readability of the code. If printed one would see the event cases like with the common event structure handling but separated by the frames of the sequence so that the printed code is a little bit structured.

[Norbert_B]

Here the example in LV 8.6

[Norbert_B]

"Strictly forbidden" is not true. But highly not recommended. The reason is simple:

1. Code can react unpredictable. Dennis already stated some things about that in your linked thread. 

2. Code is not readable and therefore not maintainable. Each event source should have only one event structure for its events. Since the UI is a single source, events from there should be captured in a single event structure. It is recommended to use this event structure as producer in a producer/consumer design pattern in order not to block the events.

3. You will most propably need timeouts in your event structure which completly negates the advantage of event driven programming. Either use event driven programming or stay at polling. Do not mix (most of all because of maintenance).

Regarding your "advantages" you listed:

- Clustering  reduces readability in therefore should never be done. Additionally, it requires timeout cases in most places which is not recommended.

- If you have such many events and interactions in your "sequence", it is a clear indication that you chose the wrong architecture for your application.

Please see attached example. Since i am not used to program with more than one event structure (except if i have different dedicated event sources), the example is "constructed" and therefore may lack of "realism". Nevertheless, it shows some issues which might occur:

- Blocking calls within the events lead to the fact that the UI is not responsive for the event time (FuncA). Nevertheless, interaction is still enqueued and if the blocking call is over, all those interaction are executed. In the example, please press FuncA and then press FuncC immediatly. You will see that nothing happens and after the 5s blocking call, the FuncC dialog appears. You also can switch tabs, but the visual display will update only after the 5s blocking call.

- In order to keep the UI responsive, FuncB is configured not to block the UI. But this is no solution: Press FuncB (on page 2) and the change to page 1 and press FuncA. Additionally, press FuncC. What happens? Just to mess things up, press Stop as well......do this combination several times. It is possible that only the lower loop is finished and the VI is still running even if Stop has been pressed.

Please note everyone that the attached example shoudl strictly be seen as "NEVER DO IT LIKE THIS". This is a negative example and shows the approach which is not recommended by any means!