mixing indicators and controls in clusters

[grahamwebb]

I have a cluster on my front panel containing various types of controls (numerical, ring etc). Two of the controls are multipled and the result is shown as an indicator on the front panel. 

From the users point of view this indicator is part of the group of data, but it sits outside the cluser, looking a bit messy. Is it possible to bring it inside the cluser, on the front panel at least?

Thanks

[smercurio_fc · Accepted solution]

This has been asked before. The answer is no. You can, however, simply have the indicator sitting "over" the cluster, but not physically in it. Select the indicator, and then using the arrow keys on your keyboard, move it over the cluster. It will not be placed into the cluster, but reside on a different Z-level. It will have a shadow in edit mode, but the shadow goes away in run mode.

[grahamwebb]

Thanks. That's quite a sneaky solution!   

[DFGray]

A simpler option is to not use a cluster at all.  You need a visual grouping, but not necessarily a programmatic grouping.  Use the decorations to group your controls.

A (bad) option is to make everything a control and use a local variable to update the result.  You will probably want to hide the increment on the result control and use an event structure to discard any changes.  It would be much easier to float the control over your cluster or not use a cluster.

[grahamwebb]

I take your point but I haven't for two reasons: I don't like the decorations in LabVIEW, as much as I try to get the levels and groups right, the decorations always get in the way when I try and move objects on the front panel. Also, clusers are beneficial to me in the block diagram. It is a very large complex piece of code.   

[GregSands]

---

DFGray wrote:

A (bad) option is to make everything a control and use a local variable to update the result.  You will probably want to hide the increment on the result control and use an event structure to discard any changes.  It would be much easier to float the control over your cluster or not use a cluster.

---

I'm not so sure this is a bad option, given I've used it more than once!  In fact, it's even easier if you set the "indicators" to "Disabled" (but not greyed out).

[DFGray]

You can mitigate the movement issues with decorations by judicious use of the group/ungroup and lock/unlock.  The former locks the relative positions of multiple front panel objects.  The latter locks a front panel object to a particular position.

I find I agree with GregS.  A simple test shows it works well.  For some reason, I seemed to remember that you have to enable/disable the entire cluster, and that is untrue.  Attached is a demo in LabVIEW 2010.  I hid the incrementers, colored the background to indicator color, and disabled the control.  Works great.

[Mark_Yedinak]

I think something worth noting is that if you decouple your UI from your processing there is no reason why you can't use the cluster definition internally but use individual controls/indicators on the front panel. The beauty of separating the UI from the processsing is that it makes it much easier to reuse the processing and give it completely different user interfaces. Yes, it is a little extra work to design your application this way but it is a much more flexible design in the long run. Your UI applications are extremely light weigth and basically just display the data passed to it by your processing code as wel as feed messages into the processing code.

[grahamwebb]

Mark, what do you mean by decoupling the the UI from the processing? Is there a direct way to control refresh rate in LabVIEW? If that's what you're referring to.

Graham

[Mark_Yedinak]

No, I'm talking about your program architecture. If you describe your application you can describe it in terms of the work performed and how it is presented to the user. When architecting the system the parts that perform the work (data collection, analysis, control logic) do not nor do they need to know about how the system will be presented to the user. Likewise, the UI does not need to know the specifics of how the work is performed. The two parts only need to know about what information they require to perform their given task. The functional component of your application should have a defined set of inputs and outputs. I am not simply talking about the connector pane of the VIs. Rather I am talking about information exchange at a more abstract level. By doing this it is trivial to reuse these components while appearing to the user that radical changes were made in your system. Or that it is a completely different system. This is accomplished via the API defined for exchanging information with the functional component of your system. You can swap out the UI completely. In fact, you don't even need a UI. You could easily plug your functional system into an automated frame work. Since you have a defined API the core functionality remains unchanged while the presentation to the user (be it a human or a machine) can be swapped out as often as you like. Ben has a really nice write up about this. (I need to bookmark it so I can refer to it at times like this.)

One way to think of this is web pages. HTML is the standard for exchanging web pages. Since it is a standard it is rather easy to develop different browsers too display web pages. They all use the HTML to access the web page itself. If the UI (the browser) and the web page (HTML) were tightly coupled both the web page and the browser would have to know about each other in great detail. Changing one part would most likely mean you also have to change the other. By establishing the API between them (HTML) either side is free to change provided they honor the API. Neither has to know how the other side is implemented nor does it care.