Tab Into Cluster

[CaseyM]

I know that if a VI is running you can use Ctrl+Down/Up to enter/exit a cluster while tabbing through the controls, but from a user's point of view this is extrememly obscure and unituitive. Is there any way to change the tabbing behavior so that it automatically tabs into (and out of) custers?

-Casey

[Rolf Kalbermatter]

QUOTE (cmay @ Apr 23 2008, 08:21 PM)

I know that if a VI is running you can use Ctrl+Down/Up to enter/exit a cluster while tabbing through the controls, but from a user's point of view this is extrememly obscure and unituitive. Is there any way to change the tabbing behavior so that it automatically tabs into (and out of) custers?

-Casey

With the event structure and key events you probably will be able to do your own customized tabbing. But I doubt this is worth the trouble. Avoiding clusters on the UI is the most simple solution by far.

Rolf Kalbermatter

[Mads]

Not an answer - but this is something I've flagged to NI a couple of times: There is no reason whatsoever for the user interface to care about cluster containers. Tabbing should ignore the fact that the controls or indicators are part of a cluster, that is only relevant for the program code, not the GUI.

QUOTE (cmay @ Apr 24 2008, 01:21 AM)

I know that if a VI is running you can use Ctrl+Down/Up to enter/exit a cluster while tabbing through the controls, but from a user's point of view this is extrememly obscure and unituitive. Is there any way to change the tabbing behavior so that it automatically tabs into (and out of) custers?

-Casey

[CaseyM]

QUOTE (Mads @ Apr 24 2008, 01:24 AM)

There is no reason whatsoever for the user interface to care about cluster containers. Tabbing should ignore the fact that the controls or indicators are part of a cluster, that is only relevant for the program code, not the GUI.

I completely agree. Is there ever a reason you'd only want to tab to a cluster container? Anyone?

[Rolf Kalbermatter]

QUOTE (cmay @ Apr 24 2008, 05:37 PM)

I completely agree. Is there ever a reason you'd only want to tab to a cluster container? Anyone?

Well I'm sure there are people that would think so. But the real issue is, that a seemingly simple request like this can have far spread effects that can and I'm 100% sure have been discussed at length in the LabVIEW development team at some point.

For starters: If you give up the current behaviour, which btw has been there since LabVIEW has clusters and allows keyboard navigation, you will likely not always just want to tab into the cluster and then go through all controls inside that cluster before going to the next outside control. That would mean a completely separate tabbing configuration independant of the cluster element order.

I'm sure there are quite a few other not so trivial questions and problems in that respect. And in my experience clusters are not really great UI controls anyhow. They restrict the design of an UI to much in several ways so that I have long ago stopped to use them on the visible UIs.

Rolf Kalbermatter

[Mads]

To make the GUI ignorant of the cluster container for tab navigation should be doable without causing any huge problems. That would solve the most annoying problem.

The ideal solution however would be to have clusters that the control panel is unaware of alltogether - so that the controls/indicators could be placed independent of eachother even if they were in a cluster. To keep things simple for beginners they could keep the old type of clusters, but add a "diagram-only cluster" for advanced users. If you want you should e.g. be able to include a control/indicator in a cluster by right-clicking on it and "cluster" it. You define a cluster much like a type definition, and then you can add or remove things from that cluster by right-clicking the control and select a defined cluster to add it to.

Yes, you can always drop the use of clusters to not get the GUI problem, but on the diagram it's very neat to work with clusters instead.

QUOTE (rolfk @ Apr 25 2008, 06:12 AM)

Well I'm sure there are people that would think so. But the real issue is, that a seemingly simple request like this can have far spread effects that can and I'm 100% sure have been discussed at length in the LabVIEW development team at some point.

For starters: If you give up the current behaviour, which btw has been there since LabVIEW has clusters and allows keyboard navigation, you will likely not always just want to tab into the cluster and then go through all controls inside that cluster before going to the next outside control. That would mean a completely separate tabbing configuration independant of the cluster element order.

I'm sure there are quite a few other not so trivial questions and problems in that respect. And in my experience clusters are not really great UI controls anyhow. They restrict the design of an UI to much in several ways so that I have long ago stopped to use them on the visible UIs.

Rolf Kalbermatter

To reply to my own thoughts here...perhaps the right-click to cluster should not be used since that ties into the control panel...instead you could create a cluster container on the diagram and drag the terminals into it instead...Isolating the clustering to the diagram.

QUOTE (Mads @ Apr 25 2008, 08:59 AM)

To make the GUI ignorant of the cluster container for tab navigation should be doable without causing any huge problems. That would solve the most annoying problem.

The ideal solution however would be to have clusters that the control panel is unaware of alltogether - so that the controls/indicators could be placed independent of eachother even if they were in a cluster. To keep things simple for beginners they could keep the old type of clusters, but add a "diagram-only cluster" for advanced users. If you want you should e.g. be able to include a control/indicator in a cluster by right-clicking on it and "cluster" it. You define a cluster much like a type definition, and then you can add or remove things from that cluster by right-clicking the control and select a defined cluster to add it to.

Yes, you can always drop the use of clusters to not get the GUI problem, but on the diagram it's very neat to work with clusters instead.

[CaseyM]

QUOTE (rolfk @ Apr 24 2008, 10:12 PM)

For starters: If you give up the current behaviour, which btw has been there since LabVIEW has clusters and allows keyboard navigation, you will likely not always just want to tab into the cluster and then go through all controls inside that cluster before going to the next outside control. That would mean a completely separate tabbing configuration independant of the cluster element order.

Why would this have to be the case? Instead of tabbing to the cluster container, LabVIEW could automatically tab to the first element inside the cluster. The overall tabbing order could still be preserved as follows:

0. Numeric Control

1. String Control

2. Cluster Control Container (ignored)

2a. Path Control

2b. Numeric Control

3. Boolean Control

Where "a" and "b" are the 0th and 1st elements in the cluster.

QUOTE (rolfk @ Apr 24 2008, 10:12 PM)

I'm sure there are quite a few other not so trivial questions and problems in that respect. And in my experience clusters are not really great UI controls anyhow. They restrict the design of an UI to much in several ways so that I have long ago stopped to use them on the visible UIs.

How do they restrict the UI design? I think in general they help clean things up rather than having individual controls on the block diagram for potentially similar and repeated sets of controls.

[Rolf Kalbermatter]

QUOTE (Mads @ Apr 25 2008, 03:03 AM)

To reply to my own thoughts here...perhaps the right-click to cluster should not be used since that ties into the control panel...instead you could create a cluster container on the diagram and drag the terminals into it instead...Isolating the clustering to the diagram.

Which is basically what I meant when I said "that I have long ago stopped to use them on the visible UIs". They are a great programming aid, but not great on an UI at all.

Rolf Kalbermatter

QUOTE (cmay @ Apr 25 2008, 03:06 AM)

Why would this have to be the case? Instead of tabbing to the cluster container, LabVIEW could automatically tab to the first element inside the cluster. The overall tabbing order could still be preserved as follows:

0. Numeric Control

1. String Control

2. Cluster Control Container (ignored)

2a. Path Control

2b. Numeric Control

3. Boolean Control

Where "a" and "b" are the 0th and 1st elements in the cluster.

How do they restrict the UI design? I think in general they help clean things up rather than having individual controls on the block diagram for potentially similar and repeated sets of controls.

Because the element order in a cluster is not always the desired tabbing order on a front panel at all anyhow. The cluster order is and should be dictated by the logical data it represents and is more often than not determined by the functionality (VIs) that operate on it. But this is more often than not, not the same that I would want a user to be presented with. For one there can be controls inside the cluster that a user should not be bothered with. For another one I prefer to have all my subVI front panels use classic controls and my UIs to use system controls. That precludes typedefs anyhow beside of the fact that typedefs do have some particular behaviour that is not making them very great to represent both the programming interface of a cluster as well as the UI interface.

Using individual controls on the UI is a bit more work initially but gives you every freedom to keep the UI completely independant of the underlying data structures, giving you the freedom to change them without having to revisit every UI to readjust just about every control on them to the new layout.

Rolf Kalbermatter

[CaseyM]

QUOTE (rolfk @ Apr 25 2008, 02:08 AM)

Because the element order in a cluster is not always the desired tabbing order on a front panel at all anyhow. The cluster order is and should be dictated by the logical data it represents and is more often than not determined by the functionality (VIs) that operate on it. But this is more often than not, not the same that I would want a user to be presented with. For one there can be controls inside the cluster that a user should not be bothered with. For another one I prefer to have all my subVI front panels use classic controls and my UIs to use system controls. That precludes typedefs anyhow beside of the fact that typedefs do have some particular behaviour that is not making them very great to represent both the programming interface of a cluster as well as the UI interface.

Using individual controls on the UI is a bit more work initially but gives you every freedom to keep the UI completely independant of the underlying data structures, giving you the freedom to change them without having to revisit every UI to readjust just about every control on them to the new layout.

You make a good point about UI tabbing order vs the logic order of data within a cluster, but I find that changing the order of cluster elements in an (un)bundle by name on the block diagram to be much easier than dealing with tons of controls on the front panel. Also, it sounds like a lot of the UI issues you brought up (e.g. classic vs system,) would be a result of using strict type defs so wouldn't a lot them be moot if you used their non-strict brethren?

[Rolf Kalbermatter]

QUOTE (cmay @ Apr 25 2008, 11:37 AM)

You make a good point about UI tabbing order vs the logic order of data within a cluster, but I find that changing the order of cluster elements in an (un)bundle by name on the block diagram to be much easier than dealing with tons of controls on the front panel. Also, it sounds like a lot of the UI issues you brought up (e.g. classic vs system,) would be a result of using strict type defs so wouldn't a lot them be moot if you used their non-strict brethren?

But clusters without (strict) typedef are really unpretty to handle when you make changes to them. I prefer to typedef my clusters whenever possible and just do the UI discretly. The clusters are arranged to be compact and logically well ordered, whereas the UI is meant to be easy to use and intuitive. Often two things that are not easily combined. Also I have many times had that the UI has changed in very strange ways due to user requests that would have been very bad if they had to be adapted to the internal logic of clusters in the actual functions too. I did use clusters in front panels for quite some time in the past but have entirely stopped with that for all these reasons.

I guess it also depends what your audience is. Mine are end users that do not care much about how I solve a particular problem inside the application but can be sometimes very particular about the UI in ways that I wouldn't even think about when programming, sometimes to the point where pedantic is just a cosy name for the requests. Having the UI as independant of the internal logic as possible has saved me many hours of work in the past when the application was completely finished and all those very specific requests suddenly started to materialize.

Things like it doesn't work like Excel are only a tiny peak of what you sometimes get to hear in those final reviews.

Rolf Kalbermatter

[Christoph Deus]

Please try the VIs (LV2014): https://lavag.org/files/file/266-enable-cluster-tabbing-tab-into-and-out-of-clusters/

 

It enables tabbing through nested clusters, also on tab controls.

 

Best regards,

 

Chris

 

How to use:

Edited August 6, 2015 by Christoph Deus