add a property to prevent an enum control from wrapping around

[Mr_M_from_G]

Hello,

I started this discussion

http://forums.ni.com/t5/LabVIEW/how-to-prevent-an-enum-control-from-wraping-around/td-p/3089021

and someone suggested to put it here in the idea exchange.

I think it would be great to have a check box in the properties window of an enum control where I can select if the enum control should or not wrap around when clicking the up or down arrow and the top most or bttom most value is reached ( and taking into acount that there may be some values disabled)

Another idea concerning enums is to enable editing the value of each entry. As much as I found out values always start at 0 and increment by one with each entry.

Hope these ideas help improve LabView

Martin

[fabric]

Regarding the first part of your idea, I'm just wondering what your use case is? Kudos anyway...

Regarding the second part, that idea already exists: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Add-sparse-enums-to-LabVIEW/idi-p/925224

[Intaris]

Well I can give an example we have.

Our software has a range of selectable filter bandwidths for operation.  Due to differences in latency, changing the filter bandwidth affects the latency of any feedback associated with that, resulting in a significant change in system characteristics (Scanning Probe Microscopy).

What we would need ot an ability to easily prevent a user from clicking "up" when the highest bandwidth is already selected and then automatically jumping to the slowest setting, possibly leading to a tip crash and destroying equipment and perhaps more importantly, measurement and sample preparation time.

[fabric]

> What we would need ot an ability to easily prevent a user from clicking "up" when the highest bandwidth is already selected and then automatically jumping to the slowest setting...

Presumably the user can still click on the enum and jump to the slowest setting anyway!  Well, at least they can *see* the ordering once they click on the enum... I guess the main point is to be able to correctly represent a monotonic list. Wrapping makes that unintuitive.

[Intaris]

The problem is that a click and hold is unstoppable once it starts.

[AristosQueue (NI)]

I would suggest the greater problem is using an Enum as an end-user UI element for situations like this.

I try to discourage using Enums on user-visible front panels generally -- it is just too common to want to display the items in a custom order for users without breaking binary compatibility or change the user-visible text late in your development cycle. Enums have no business being on end-user panels. Drop a different control (Ring, most commonly) and then translate the value of that control into the enum on the block diagram.

if you've got critical selection issues like this one, that general advice becomes even more important. Use radio buttons or some sort of confirmation control (i.e., you change the value and then click a separate button to confirm -- very annoying to users but something I've seen used successully in high-risk UI scenarios) on the panel. Translate to enum on the diagram.

[Intaris]

AQ, rings have the exact same problem. Should we stop using them on the UI also?

But anyway someething which bugs me since a while. One of the great features of LV is that EVERY VI has a UI, most of which are used for debugging. Why are we programmers expected to work around or intuitively know about problems like this instead of treating a programmer who happens to be debugging the same as any other "user".  Debugging UIs suffer from this kind of behaviour as others. And perhaps even worse because such UIs are considered "free" in LV and such intricacies of controls behaviour go unchecked. Equal rights for debuggers i say!

[AristosQueue (NI)]

> AQ, rings have the exact same problem. Should we stop using them on the UI also?

Hm... if that's what you got from my post, then I didn't explain something right. Let me try to clarify.

There are problems of enums that rings do not have. Those problems mean that I discourage the use of enums on panels. This applies to users generally.

Then Mr_M_fromG comes along with a particular problem of having a setting that is too easily changed. That's a separate issue. He asks for a fix on Enums. Rather than try to provide a new feature on enums, I would look to a totally different UI element, like the two that I noted.

In other words: I would not use a Ring for this particular problem. I would use Rings for other problems. But Enums are right out for end user UIs.

[Intaris]

I think you whether rings or enums are used, the automatic wrapping behaviour of the current elements feels very wrong.

The problem the OP is trying to solve cannot be translated to a ring vs enum argument. While many points you make are technically correct, they get us no further with this particular problem. And no, confirming each and every change is not a good solution. Neither is a 16 element radio button.....

Enums and rings should not automatically wrap regardless whether they are on debug UIs or end user UIs.  The programmer should have a choice.

[AristosQueue (NI)]

> Enums and rings should not automatically wrap regardless

> whether they are on debug UIs or end user UIs

I can accept that. But the guy started off proposing a solution involving Enums. And I'm trying to steer him away from Enums.

With regards to Rings -- I went looking. I found other apps with rings -- seemed there was about a 50/50 split in behavior, so I'm ok with LV adding this as an option. I still would guide the guy away from using an Enum.

[Intaris]

Still missing the point.  This is not a ring vs enum issue.  If the title chanted the word enum to ring would that be more suitable?