Jump to content
KoBe

MainVI control-events packed in SubVI Event Structure ?

Recommended Posts

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!

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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

  • Like 2

Share this post


Link to post
Share on other sites

Thanks for being the exception to the rule, Ben. ;)

  • Like 1

Share this post


Link to post
Share on other sites
...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.

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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).

  • Like 1

Share this post


Link to post
Share on other sites

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).

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.