Modifying Controls in different frames of a State Machine

[Diego Reyes]

Hi Everyone,

I have about 30 Controls that I have to modify differently in each one of the states of my UI state machine. I would like to know what is the best way to implement this process. I have asked several colleagues and they have provided various options. Please, let me know what you think:

Option 1

Use property nodes directly linked to the control I want to modify. This will mean that I will have more than 90 property nodes in my block diagram

Option 2

Create references to all my controls, bundle them into a cluster and pass it into my state machine using a shift register. Then when the application ends, close the references.

If I was to use option 2, Do I have to close the references after I use them?

In advanced, I thank you for your input.

Regards,

DFR

[asbo]

I believe that per NI, that "best" method is to use directly linked property nodes. I feel like this was a question on the CLAD or something.

My preference would probably be Option 2, just because it's going to be much cleaner overall. I don't know why this is considered worse than using directly linked property nodes.

While you may be able to get away with not closing your references (LabVIEW will probably garbage collect them of its own accord) it's absolutely best practice to close them yourself.

[jcarmody]

QUOTE (Diego Reyes @ May 1 2009, 06:52 PM)

Please, let me know what you think

I think I'd use a dedicated state to update the UI elements based on a cluster of settings passed in the shift register. Route the machine there after updating the cluster in your other states. I got this advice http://forums.jkisoft.com/index.php?showtopic=936' rel='nofollow' target="_blank">here.

Jim

[Chris Davis]

Control references are something that you don't want to close until you are completely done with them, like at the end of the program. I do believe that you don't actually have to close them anymore, as LabVIEW will take care of them, although closing them explicitly is still considered the best practice. You may also want to look at using a subVI that has the ability to change the same property(or properties) on controls by the label text of a control. All control references can be gathered dynamically from LabVIEW using the built in VI Server methods (All Controls []), then label text can be gathered in a for loop and searched to find specific references. I don't have an example with me, and I don't have LabVIEW loaded, but if this doesn't make sense, I can upload a snap shot.

Chris

[ShaunR]

This is something I deal with on a daily basis. Many of my screens have 30+indicators/controls.

The most convenient way is to cluster the controls/indicators on the front panel then just pass the cluster in to the state machine and use option 1 or unbundle and re-bundle to change the values

I don't like using the references as per option 2 since you end up with a huge diagram full of references (just take a look a the Navigation demo in the LVOOP examples directory and you'll see what I mean).

[Aristos Queue]

QUOTE (Diego Reyes @ May 1 2009, 05:52 PM)

Create references to all my controls, bundle them into a cluster and pass it into my state machine using a shift register. Then when the application ends, close the references.

I'm not commenting on the pros/cons of the two architectures. I just want to point out that if you choose the 2nd idea, you don't have to worry about closing control references. Control references all close when you close the VI that owns those controls. You have to be careful to close any App references that you open and close any VI references that you open, but not control references (the same applies, if you use scripting, for all the block diagram references). Having an App reference open will keep LV from quitting. Having a VI reference open will keep the VI from leaving memory. But having a control reference open won't keep anything in memory. Those go stale as soon as the VI unloads.

[Mark Balla]

QUOTE (Diego Reyes @ May 1 2009, 05:52 PM)

Hi Everyone,

I have about 30 Controls that I have to modify differently in each one of the states of my UI state machine. I would like to know what is the best way to implement this process. I have asked several colleagues and they have provided various options. Please, let me know what you think:

QUOTE (Chris Davis @ May 1 2009, 10:20 PM)

You may also want to look at using a subVI that has the ability to change the same property(or properties) on controls by the label text of a control. All control references can be gathered dynamically from LabVIEW using the built in VI Server methods (All Controls []), then label text can be gathered in a for loop and searched to find specific references. I don't have an example with me, and I don't have LabVIEW loaded, but if this doesn't make sense, I can upload a snap shot.

Chris

Here is an example of what Chris is talking about. I use this method when I need to disable/hide several controls or groups of controls.

Download File:post-584-1241300774.zip

Hope this helps

[ShaunR]

QUOTE (ShaunR @ May 2 2009, 08:04 AM)

This is something I deal with on a daily basis. Many of my screens have 30+indicators/controls.

The most convenient way is to cluster the controls/indicators on the front panel then just pass the cluster in to the state machine and use option 1 or unbundle and re-bundle to change the values

I don't like using the references as per option 2 since you end up with a huge diagram full of references (just take a look a the Navigation demo in the LVOOP examples directory and you'll see what I mean).

Like this. Its very easy to manage.

[Diego Reyes]

QUOTE (mballa @ May 2 2009, 04:46 PM)

Here is an example of what Chris is talking about. I use this method when I need to disable/hide several controls or groups of controls.

Hope this helps

mballa, Thank you for the sample code :thumbup: . It help me to visualize Chris' idea . I will use something similar to organize my UI. I have to disable/enable groups of controls at different parts of my application. Using groups should make my code cleaner and easier to maintain.

[Jarimatti Valkonen]

QUOTE (ShaunR @ May 3 2009, 02:10 AM)

Like this. Its very easy to manage.

Hey! Why didn't I think of this before? Looks very nice and simple.

I'm actually considering using this or similar approach for my next UI. In previous project I used the "references inside cluster" approach and it didn't feel like data flow. I made a separate VI with the cluster of references as a pass-through value to update the indicator values and some control properties. When the UI needed an update, I simply placed the VI in the block diagram.

I'm having this strange idea of Model-View-Controller paradigm: keep the state (model) as a single cluster in a shift register and unbundle after every state to indicators (view). Something quite like presented here, but with additional "hidden variables" inside the model cluster.

[ShaunR]

QUOTE (Jarimatti Valkonen @ May 4 2009, 08:33 AM)

Hey! Why didn't I think of this before? Looks very nice and simple.

I'm actually considering using this or similar approach for my next UI. In previous project I used the "references inside cluster" approach and it didn't feel like data flow. I made a separate VI with the cluster of references as a pass-through value to update the indicator values and some control properties. When the UI needed an update, I simply placed the VI in the block diagram.

I'm having this strange idea of Model-View-Controller paradigm: keep the state (model) as a single cluster in a shift register and unbundle after every state to indicators (view). Something quite like presented here, but with additional "hidden variables" inside the model cluster.

If your going with a model-view architecture the (very) old method of using a data pool works well.

If you put all your data in a global vi or variable and get your controller to update the global, you can bolt on different UI's for different views.

[Jarimatti Valkonen]

QUOTE (ShaunR @ May 4 2009, 12:33 PM)

If your going with a model-view architecture the (very) old method of using a data pool works well.

If you put all your data in a global vi or variable and get your controller to update the global, you can bolt on different UI's for different views.

Thanks for the info. I had actually tought of that in regard to logging like Log4x, but had not thought about it in general UIs.

There are, of course, issues with global variables and even with global VIs. One must be careful to avoid race conditions.