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

Question

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.

Answer 1

"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!
CEO: What exactly is stopping us from doing this?
Expert: Geometry
Marketing Manager: Just ignore it.
Attachments:
Never EVER86.vi ‏10 KB