Tip Strip on Case selector must display all the values if the case has multiple values

[P@Anand]

When we have multiple Enum values using a same case it is difficult to see what are the values using it. It would be good if we have a Tip strip showing the values handled in that particular case would be more meaningful instead of having "Selector Value" as a tip strip.

There is also an idea on removing the tip strip totally and it got fair response.

Please ignore if already suggested!

[X.]

This idea appears related to this one and others cited in it.

But in any case, what you are suggesting is probably not the best approach.

Imagine very long case names, very long cases lists, etc.

And remember that tip strips are limited in terms of width and number of characters, so they would at some point fail.

In general, LabVIEW has a big problem with long lists, whether it is to display them vertically (see this suggestion) or horizontally (I couldn't find a thread about is specifically, but I recall having mentioned this and read about it several times over the years).

The QD plugin of jcarmody might be a good starting point to revisit all these issues (moreover it has its own set of issues, so there is a lot to learn form it).

This range syntax is in any case contrary to the proclaimed LabVIEW philosophy (or style recommendation) to not hide anything...and has its issues.

[P@Anand]

I propose NI to take it whichever way it is but the end goal is to see the items in contained in that particular case or the Sub diagram. My point is simple, I want to see the items for a particular case easily since there is no option (In LabVIEW) other than selecting the selector label and move the cursor across the items.

[X.]

Well, I guess what I am warning against is this:

[P@Anand]

I understand 🙂 If it is a sequence we can still show that with the start and end elements separated by 2 dots. I was more concerned about the non sequential items getting hidden inside the selector and we have no way to check them easily.

[Yamaeda]

I like this idea! Sure, it can be argued if it should be comma separated or one item per row, but seeing more (all) enum items is quite helpful, i have many times needed to look at the help-window or even drop a enum constant just to see which cases exist and which one's really included! (especially when inheriting code)

/Y

[Manzolli]

For long lists, the number of shown item ca limited to a certain number or size ins screen followed by "...", jus like a long path. Kudos!

[X.]

The suggestion is about using a tip strip. I do not believe that this is the right way to go for the reason I exposed (lack of flexibility).

To further document my qualms about the current disregard of LabVIEW for this kind of situations (which I do not deny), here is another problem in the Event Structure:

The list (without a scrollbar...) is truncated HORIZONTALLY because of what is possibly a Windows 7 limitation.

In any case, it is impossible to figure out the full list of events handled by this specific case, unless you open the "Edit Events Handled by This Case..." pop-up window.

There you get a complete list (Listbox), which is easily navigated and resizable.

I believe this is a much more robust approach than the tip strip one (tip strip which we agree is currently pointless and annoying). And this would connect the current idea to this long outstanding one: Rejuvenate the "Rearrange Case" window of the Event Structure (which mentions the Case Structure as well. Also, check Darin. K's comment at the end, it will certainly ring a bell).

In fact, the proposed solution would arguably be even more annoying that the current behavior, because the tip strip would cover even more real estate.

OK, longish vote down, but I just wanted to point out the unintended consequences of the proposed solution to a real problem.

[GregSands]

X, I think the problem you describe should rarely happen with Enums, which is the use case suggested.  As you say, it doesn't make sense to list all numerics in a case, as the compact notation gives all the information, but with Enums it is difficult to know exactly which items are included in a range.  I do agree with you that a dialog may be better, although in this case much slower than a tip strip.

[P@Anand]

"because the tip strip would cover even more real estate."

Why do we have to worry about Tip Strip covering the BD real estate? 

BTW I never recommended to display all the consecutive numbers in a particular case (for example 1 to 100 still be shown as 1..100) the main intention is to know what are non-consecutive numbers contained in a case (Either it may be integer or an Enum). This is also applicable to the String case selector