MainVI control-events packed in SubVI Event Structure ?

[KoBe]

Hi people,

i have quite a big project and therefore I would like to make the block diagram of my MainVI more readable. There are several parallel task packed in SubVI's, which looks really pretty. The last challenge for me is the Event Structure of the MainVI. With this Event Structure I react on user input on the MainVI Controls and Indicators. At the moment I haven't implemented any User Events. Now I'm searching for a possibility to move the Event Structure of the MainVI in a SubVI to make it also more compact. Is the a possibility to do that? In fact this would mean, a SubVI must be able to handle Events fired by it's MainVI. Can anyone help me please?

Thanks in advance!

[asbo]

You can wire control references into a Register For Events node to create a dynamic event refnum that can be passed into a subVI. Once in the subVI, perform the registration for your dynamic event refnum. In general, though, it's best to leave a UI-related event structure in the VI it responds to.

[Grampa_of_Oliva_n_Eden]

You can wire control references into a Register For Events node to create a dynamic event refnum that can be passed into a subVI. In general, though, it's best to leave a UI-related event structure in the VI it responds to.

Well I never learned that leason so being the fool that I am I went off and started pushing evnts down into the sub-VI that handle each of the modes the app runs in. I will not multiply words but I will invite you to examine the images I uploaded to the Dark-side that can be found here.

This approach lets me develop sub-VI that are clean and focused on only the events that apply to the current operating mode as shown here.

If you really want to rad more about this approach see this thread on the Dark-side.

Ben

[asbo]

Thanks for being the exception to the rule, Ben.

[jgcode]

...the sub-VI that handle each of the modes the app runs in.

Another example includes making skinable UIs - if you want to have two different UI themes or resolutions etc... The UIs should be thin (to avoid redundancy) and you have an engine VI to handle events.

I have made a thin UI before so as to disassociate the UI from engine. Its more work but can be beneficial.

[Val Brown]

Now that kind of skinnable, thim UI sounds very interesting. Any examples you can post?

[KoBe]

You can wire control references into a Register For Events node to create a dynamic event refnum that can be passed into a subVI.

This short instruction answers already all my questions. Thank you!

Well I never learned that leason so being the fool that I am I went off and started pushing evnts down into the sub-VI that handle each of the modes the app runs in. I will not multiply words but I will invite you to examine the images I uploaded to the Dark-side that can be found here.

This approach lets me develop sub-VI that are clean and focused on only the events that apply to the current operating mode as shown here.

Your picture made me understand the short instruction from asbo. Thanks you!

[jgcode]

Now that kind of skinnable, thim UI sounds very interesting. Any examples you can post?

On the road, so don't have any examples with me however, the JKI Module presentation shows how you can 'fit' a UI onto another module and the old LabVIEW Advanced course showed two examples (Event Structure and Queues) for doing this - if you can get your hands on that book it is a good read.

Cheers!

[mje]

Well I never learned that leason so being the fool that I am I went off and started pushing evnts down into the sub-VI that handle each of the modes the app runs in. I will not multiply words but I will invite you to examine the images I uploaded to the Dark-side that can be found here.

This approach lets me develop sub-VI that are clean and focused on only the events that apply to the current operating mode as shown here.

Indeed, I do the same. My only real rule is to "never" pass event registration refnums to subVIs due to the static typing. The event registration always stays in the VI that has the event structure using the registration, but I impose no restriction on where these are relative to the actual event source(s).

[asbo]

Indeed, I do the same. My only real rule is to "never" pass event registration refnums to subVIs due to the static typing. The event registration always stays in the VI that has the event structure using the registration, but I impose no restriction on where these are relative to the actual event source(s).

This is a good explanation of what my prescribed "best practice" is really looking to prevent. I fully support using GUI controllers as long as event refnums aren't being created and destroyed at different levels of the architecture (I updated my first post to not encourage this).