Indicate that array constant contains more elements than currently visible with scroll bar

[d.w.b]

Scroll bar should be disabled if all elements are visible! Kudo here to get a big bang for the buck sooner than the 2nd in TOP KUDOED IDEAS from 2013 with 600+ kudos (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Indicate-that-array-constant-contains-more-elements-t...). It points out that the scroll bars are not a viable method because it looks the same when all elements are visible. That is EASY to fix; disable the scroll bar if ALL elements are visible! Currently it is disabled only if an empty element is visible. Perhaps the behavior was originally by design like block diagram scroll bars as mentioned in the reason that the following was Declined, '...without this "boundary", it is impossible to create more space...' but constants can easily be stretched by border handles to create more elements (https://forums.ni.com/t5/LabVIEW-Idea-Exchange/Make-window-scroll-bars-reflect-actual-contents-of-wi...).

[d.w.b]

[wiebe@CARYA]

Adding elements to the array will become (slightly, but still a few clicks) harder. You'd have to first scroll to the last element, and then extend the array size.

Just saying... People might complain as they are used to how it is.

This is probably one of those ideas where you'd also want anti-kudos, because the kudos won't show how many people are against it (if any. of course).

[fefepeto_kb]

@wiebe@CARYA, we might as well just Kudo the comment that is against it.

[d.w.b]

---

Adding elements to the array will become (slightly, but still a few clicks) harder. You'd have to first scroll to the last element, and then extend the array size.

No clicks more; currently you must scroll to the end to append a new element. If it was already large enough to show the empty element you will likely extend it again, so it changes from click/extend to extend/click.

[wiebe@CARYA]

Adding elements to the array will become (slightly, but still a few clicks) harder. You'd have to first scroll to the last element, and then extend the array size.

No clicks more; currently you must scroll to the end to append a new element. If it was already large enough to show the empty element you will likely extend it again, so it changes from click/extend to extend/click.

Now I'm just confused.

Unless I'm missing something, with this idea, you can't scroll to show the empty element. So you have to scroll to the last element, and then extend the array by growing the number of elements. Only then you can add the element. Yes, if you want to add 2 or more elements, that is only one action...

I usually don't grow an array 2 elements to add one, presuming I want to add another one later...

[wiebe@CARYA]

My previous objections were based om my (wrong) idea that the scrollbar is also coerced on it's max value, preventing scrolling.

This isn't the case as it is, and it won't be in the proposed idea.

Here's a breakdown of all situations:

There's only one situation where adding an element is different (not harder per se).

In this situation (an exact fit) you probably want to grow the array anyway, so all elements are shown after adding an element.

So, after some DM correspondence that let to this breakdown, I now feel that it gives better insight without any disadvantages.

+1 for me.

[fefepeto_kb]

It might sound like nitpick, but I still have some objections against the idea. If the array constant is in a tight space, because that is restricted by some other objects (i.e. inside a cluster) it would be inconvenient to have the container (especially if it's in a structure, maybe even nested, which I prefer to have the auto grow turned off all the time). I would not prefer to have to resize the container and the array as well. I like to scroll to the end, just enter the value(s) and forget about it.

Don't get me wrong, it would be nice to get a dedicated designator to show if the array has more elements, but I don't like the idea to take something away to achieve this feature. Especially because I worked at NI, and the style guide there forced the developers to set the constants so that their size is always explicitly readable.

[wiebe@CARYA]

> I would not prefer to have to resize the container and the array as well. I like to scroll to the end, just enter the value(s) and forget about it.

This would happen only if exactly the number of elements in the array shown.

In this case, you don't need to grow the array to get a scrollbar, you can also shrink it to get a SB. Or you can use the index.

In real tight spaces I'd normally hide the index. But I'd also hide the scrollbar if things are really tight.

[fefepeto_kb]

> In this case, you don't need to grow the array to get a scrollbar, you can also shrink it to get a SB. Or you can use the index.

Actually, growing and shrink is more effort then clicking the scroll bar, which has a larger catchment area then the index control. From this perspective the scroll bar is a minor but useful function.

Actually, I find growing the array a bit painful, mostly because I have to grab exactly the edge of the array control. From this perspective, I prefer to have the edge, over which the resize can happen thickened or replaced with double line. In that case an indicator could be placed in that area showing that there are more elements.

So my objection is really about using the scrollbar for this.

In general, I don't think that a function of a user interface should be removed or changed to achieve a new functionality. I know there are cases when it is debatable, i.e.: the zoom shortcut in, but I prefer to have my old functionalities available.

[d.w.b]

Overall I think it better for the scroll bar to behave in a standard manner and correctly represent the list contents rather than "overloading" its behavior with one of the empty elements thus making it differ from the norm. The payoff will be continuously visible versus an isolated, minor inconvenience. As you suggest, other ideas may be submitted to improve the interface but let's not convolute the simplicity of this idea which solves the top kudoed idea from 2013 still unimplemented.