Registering Events in SubVIs

[Jordan Kuehn]

Here's possibly a simple question. I'd like to have a main program that launches subvis which provide the main UI. I don't want the subVIs to handle events though, I want the single controlling process to get the events and handle them. Is there an easy way to do this, or will I have to create custom user events for every single one I want using control references?

[Tim_S]

Here's possibly a simple question. I'd like to have a main program that launches subvis which provide the main UI. I don't want the subVIs to handle events though, I want the single controlling process to get the events and handle them. Is there an easy way to do this, or will I have to create custom user events for every single one I want using control references?

Offhand that sounds like a Producer-Consumer model. You should be able to find an example on NI's website.

Tim

[Wire Warrior]

jkuehn,

You can do what your wanting by using dynamic events. If you search for that in the example finder I believe you will find some examples. Basically you need to pass the reference for the control of the subVI to the 'control' VI where you will register the specific type of event you want to process, mouse over, value change, etc.

Jason

[Jordan Kuehn]

the problem is that the UI code exists within the SubVIs. I will be pumping data into them in a producer-consumer fashion, but need to get User Interface events from them.

jkuehn,

You can do what your wanting by using dynamic events. If you search for that in the example finder I believe you will find some examples. Basically you need to pass the reference for the control of the subVI to the 'control' VI where you will register the specific type of event you want to process, mouse over, value change, etc.

Jason

Ok. That's what I was hoping to avoid, but I can make that work.

[PaulL]

Well, an approach we use differs in letter from what you are attempting, but maybe accomplishes the larger goal.

Our Views do handle control events (that's the easiest place to handle them!), but when an event happens they send a message to the Controller, which instructs the Model what to do. In some applications the messages are commands using the Command Pattern, so that we can use one message type (of the top-level Command class) and therefore a single message pipe (user event, shared variable, queue, or other messaging system). (In practice we often send basic shared variables from the View and then translate these to Commands before sending them to the Controller, because the messages may come from various sources, but that is a fine point.)

Paul

[Jordan Kuehn]

Well, an approach we use differs in letter from what you are attempting, but maybe accomplishes the larger goal.

Our Views do handle control events (that's the easiest place to handle them!), but when an event happens they send a message to the Controller, which instructs the Model what to do. In some applications the messages are commands using the Command Pattern, so that we can use one message type (of the top-level Command class) and therefore a single message pipe (user event, shared variable, queue, or other messaging system). (In practice we often send basic shared variables from the View and then translate these to Commands before sending them to the Controller, because the messages may come from various sources, but that is a fine point.)

Paul

I've read your whitepaper and I like your approach in general. Have you released this code for public use or is it proprietary? You can pm me if it's going to derail this forum thread.

[PaulL]

I've read your whitepaper and I like your approach in general. Have you released this code for public use or is it proprietary? You can pm me if it's going to derail this forum thread.

We've learned a lot since I wrote the white paper, and I have since created a system component template that I consider to be immensely successful. It allows us to concentrate on the specific application rather than the details of messaging and the like since those are a given, and creating and debugging an application is orders of magnitude more straightforward, we have found. We have pondered releasing the template in some manner, but we haven't yet. Will you be at NI Week? If so, perhaps the best thing is to attend my session,

Track: Software DevelopmentTechniques

Session ID: TS1665

Title: System ComponentsWith Object-Oriented Design Patterns

Speaker(s): Paul Lotz with LowellObservatory

Date: Tuesday, August 2

Time: 1:00 PM

Room: 14 (located on the 4^thfloor of the Austin Convention Center),

and we can talk then about what would be most helpful....

[Jordan Kuehn]

I'll put it on my calendar. See you then.