Handle one case with different type sources in Event Structure

[rolfk]

---

@rpicazof wrote:

Hi GerdW and RavensFan,

thank you very much for the quick response! Definitely what you suggest would work, but I discarded this idea since the code I want to implement is absolutely humongous and embedded in a very dense front panel that I don’t want to detach. It seems strange that event structure cannot handle this situation… I was wondering if using some kind of  “variant” would do the trick, but I could not figure it out.

---

Why should the event structure implement some weird, unintuitive, complicated and inconsistently supportable functionality to allow some user to reuse humongous code that can't be refactored into a proper subVI?

It would appear to me that the main problem here is not the event structure not allowing you to handle this situation, but said humongous code you don't dare to touch.

It's possible to combine events in one frame but if they are of different type only the event attribute data that is common to all events is available. The only exception is that you can not combine filter events and non filter events, since a filter event by definition needs one of the output terminals being set, while non filter events have no such terminal at all. There is no good way to allow something different.

[rpicazof]

Hi rolfk,

thanks for your response, I wonder how you can conclude that my code is weird, unintuitive, complicated and inconsistently supportable functional without having seeing it, but let me explain a bit further.

I want to have one front panel from which my whole experiment is conducted, so that the user have everything at hand in one place. When I press the Boolean GO, the event happens in which the code I am trying to run writes all the data, and performs Analog/ Digital Input/Output for some amount of time, and save the data. This piece of code would correspond to several tabs in my Front Panel. 

Now I also have some tabs to process the data, in the same Front Panel, by running a while loop asking if a new scan in the folder is found. 

Now correct me If I am wrong, were I to use subVIs:
(1) I can run them separately, in which I would have to go to the subVI to change controls values for different experiments, and there would be no single Front Panel from which to control everything -or-
(2) I can wire those controls with terminals in the subVI, but then again if I have 100 controls, this would be very complicated to wire them all to the subVI icon.

This is the reason I have chosen to code the program in this manner. 
Cheers,

[GerdW]

Hi rpicazof,

---

@rpicazof wrote:

I wonder how you can conclude that my code is weird, unintuitive, complicated and inconsistently supportable functional without having seeing it, but let me explain a bit further.

---

You wrote your code is "humongous"…

---

@rpicazof wrote:

Now correct me If I am wrong, were I to use subVIs:
(1) I can run them separately, in which I would have to go to the subVI to change controls values for different experiments, and there would be no single Front Panel from which to control everything -or-
(2) I can wire those controls with terminals in the subVI, but then again if I have 100 controls, this would be very complicated to wire them all to the subVI icon.

---

(3) The user can only see the content of just one tab at a time, so you can place the functionality for each tab into their own subVIs. Then you replace the whole tab container by a subpanel and only show one of those subVIs by user selection… (See the LabVIEW options dialog as an example of this technique.)

[rolfk]

---

@rpicazof wrote:

Hi rolfk,

thanks for your response, I wonder how you can conclude that my code is weird, unintuitive, complicated and inconsistently supportable functional without having seeing it, but let me explain a bit further.

I never said anything like that! What I said is that if the event structure would allow what you think it should and felt annoyed about that it didn't, it (the event structure) would be unintuitive, complicated and inconsistently supportable. That's very different from what you claim I said!

I want to have one front panel from which my whole experiment is conducted, so that the user have everything at hand in one place. When I press the Boolean GO, the event happens in which the code I am trying to run writes all the data, and performs Analog/ Digital Input/Output for some amount of time, and save the data. This piece of code would correspond to several tabs in my Front Panel. 

Now I also have some tabs to process the data, in the same Front Panel, by running a while loop asking if a new scan in the folder is found. 

Now correct me If I am wrong, were I to use subVIs:
(1) I can run them separately, in which I would have to go to the subVI to change controls values for different experiments, and there would be no single Front Panel from which to control everything -or-
(2) I can wire those controls with terminals in the subVI, but then again if I have 100 controls, this would be very complicated to wire them all to the subVI icon.

This is the reason I have chosen to code the program in this manner. 
Cheers,

---

There have been numerous suggestions in this thread how you can handle it. The by far cleanest and best solution would be to simply put that common functionality into a subVI and use it in whatever event case you need that functionality. If you can't do this because you fear to touch this VI in order to make it a clean subVI, there have been at least three other options mentioned how you can still solve that problem. I could think of several more such as a separate loop where you place this VI, with a queue that you send an element to from your different event cases to tell it to execute that "humongous" VI.

[rpicazof]

Oh It seems that I misunderstood you then, apologies! Alright guys, it seems that subVI is the way to go, I will try to write it in a subvi while keeping a single Front Panel, as @GerdW suggests in point (3). Thank you

Cheers,

[Eric1977]

Based on what I've read so far, I see two things:

1. You need to understand what the "humongous" code is doing. I am sure there are FAR BETTER WAYS to achieve the functionality you want and the flexibility you desire without even seeing any code. Others have pointed this out to you. Take one part that seems complex and I bet the collective minds here can make it easy to understand just by implementing, most likely, simple functions.
2. You don't seem to really understand LabVIEW. I get the impression you're at the beginning stages. We've all been there. Take advantage of the free tools NI gives you. They are good. I'd stay away from YouTube tutorials. Almost all seem to implement bad coding practice. Most notability, not connecting error wires.