Any suggesstions on how to manage 100+ indicator and containers

[Tim_C.]

I have an app I have been rewriting in an effort to ease life cycle support  ( I won't mention it was one of my first apps and my code looks like spaghetti) 🙂

I have two areas I could use some advice on

1.  There are so many buttons that the event structure drop down list becomes quite long and becomes a pain to use.  What are some good ways to overcome this?  I thought of using multiple Que / Producer loops  or multiple event structures in the same while loop but was afraid that could lead to a race condition.

2.  Where is the best place to hold ALL the controls?  Inside a while loop or outside the while loop in a stacked frame to keep them in goups

without taking up a lot of screen space?

Thanks

Tim C.

[MikeS81]

Hi Tim,

you can read all references of your controls and create user events of it. So you only need to create the user event in your event structure. You can differ between them if you read the control name from the reference. Depending on which action you need from the controls it could be better to place them in the specified event case.

Hope it helps.

Mike 

[Ben]

Quick reply (I could talk your ear off for this Q)

Divide and conquer!

Figure out how to use dynamic event registration and create sub-VIs for related tasks.

I put the control/indicator in the event structure that is configured to watch it. THis way i can double click on the control and get right to the code that handles it.

I'll let others fill in the rest of the blanks.

Ben

[Tim_C.]

Ben I believe I understand you answer but if I use an event structure to watch 100 controls the drop down list of the event structure becomes very long and ends up taking a while to find the correct event if code changes are required.

Is it ok to use multiple event structures?

Or perhaps multiple while loops as well?

I would be happy if I could keep the drop down list at aroud 25 items.

Thanks

[MikeS81]

Hi Tim,

i think one event structure per vi should be enough.   Do all your controls have different functionality?

Mike 

[Tim_C.]

I have a TOP VI that is the GUI and Que Producer.

The goal was to use many VIs through a que scheme  (nothing new here).  The que would use an event structure to launch sub vi's

but there are so many controls that I find that the producer loop event structure is the one growing out of control just to control GUI functions

such as changing pages of containers or enabling or disabling controls.

so if this info seems redundant, just trying to give the GUI overview.

Thanks

Tim C.

[Tim_C.]

Ben's suggestion of placing the control in the loop to gain quick access just clicked 🙂

Is there any other benifits to keeping the control insid ethe event?

This brings up another point about the event.  What is the best way / type of event for buttons that are latched until released?

I have had issues in the past with using "value change" type events that results in the operation being ran twice.  Once when the button is pressed and once when the button is released.  Does placing the control inside the event stop this?

To prevent the dual code scenerio I have switched to "mouse down" events but have had times when the code was ran even when the control was disabled, but because a mouse click was detected it still ran the code.  To prenet this I have added a property node value check case inside the event to ensure the code is ran only when the value of the control is in the correct state.

So how are these problems avoided with events?

[Kevin_Price]

A friendly thought: maybe providing simultaneous access to ~100 controls isn't really a favor to the operator (even if the operator is often you).

I've found that when I have lots and lots of possible parameters to tweak, I don't generally need to provide instant access to every single one of them.  Most of them can be stowed away on a separate config screen which the user can open separately to make relatively infrequent changes.  Only about 10 or fewer of the most-commonly changed items will be on the instant-access screen.

Strategies for getting there from here: learn to use config files for loading and saving a screen full of controls' values.  After that, consider organizing the controls into logical groups.  Then you could store settings for the individual groups of controls.

If indeed many of the controls are boolean buttons, and you have dozens of them, I suspect that there are some logical grouping possibilities. 

-Kevin P.

[tst]

I would also advise considering subpanels or pop-up VIs. This will allow you to move code into subVIs and simplify the main VI.

With regard to your question about multiple loops with event structures, there's no real problem with that, as long as you:

• Don't handle the same event in more than one loop.
• Don't wire event registration refnums to more than one loop.
• Don't have a race conditions caused by having multiple events fire close to each other.
• Use filter events without understanding how they are handled. 
• Probably some others.

The main problem with this is that you create a potential for race conditions and that figuring out which event should go in which loop might be tricky.

---

Tim C. wrote:

Is there any other benifits to keeping the control insid ethe event?

---

As you mentioned, latched controls are a good reason. A latched boolean unlatches when the terminal is read in the diagram. This is a good reason to place the boolean in the event case, because that code is guaranteed to execute when the control changes value and will thus unlatch it. Your double events comes from using latch until released. If you want the event to only occur when releasing the control (which is a standard UI behavior for Windows, at least), just leave it at the default latch when released.

[tst]

P.S. For a good example of subpanel use, look at the LabVIEW options dialog. The listbox on the left loads a new VI whenever you change it and the actual code for each section is found in a separate VI.