Indicate that array constant contains more elements than currently visible

[SteenSchmidt]

Hi,

When I use array constants on the block diagram I often expand them to show how many elements they contain - I even expand them one element further than their contents to leave no doubt that no elements are hiding below the lowest visible element:

Often it's not so important to know how many elements are in the arrays, nor even their values (one can always scroll through the array if one needs to know). But it can be very important to not get a false impression of a fewer number of elements than is actually present, for instance when auto-indexing a For-loop:

To be able to shrink array constants to a minimum size while still signalling that they contain more elements than currently visible, it would be nice with an indicator on the array constant when it's shrunk to hide elements (here shown with a tooltip that would appear if you hover on the "more elements" dots):

The information in the tooltip would be better placed in context help, but the important aspect of this idea is the "more elements" indicator itself.

Cheers,

Steen

[SteenSchmidt]

Or maybe the array should simply show a tiny bit of the adjacent row/column unless fully inflated? Two examples of this (top row shows a bit more than bottom row):

Both of these has the drawback of using up more BD real estate than the current implementation.

/Steen

[SteenSchmidt]

I still think it's a bit confusing if the "more items" indicator is so similar to the typedef one:

But maybe a plus sign instead then?:

/Steen

[fabric]

I see you still prefer black, huh? 

Yes, the plus sign is ok by me!

Here's another possibility: What if the "more items" indicator doubled up as a drag-to-resize handle? (Sorry, no artwork yet...)

• For arrays with all elements visible, the drag handle could be displayed only on hover. (This would allow easier resizing than the precise "micro mouse movements" that are sometimes required!)
• For arrays with hidden elements, the drag handle could be permanently visible.

[SteenSchmidt]

Well, not exactly black, it's gray-70 as the other glyphs of similar nuance . But yes, I feel red is signaling an error condition too much...

/Steen

[donkdonk]

My first thought: yes kudo this.

However, reading through all the comments, I hesitate. The visuals proposed here are not convincing me. The thick line at the last element makes me think of a railhead, meaning you've reached the end, instead of "there are more elements".The typedef "lookalikes" are probably a bit confusing and may be used for other purposes in the future (I admit I don't have a purpose for them yet).

So, all in all, I like the idea but a better glyph needs to be found.

Anyway, thanks everybody for the nice graphics!! It makes it easy to comment.

[tst]

donkdonk, you shouldn't be voting based on the mockups. If you think the idea is good, then vote for this and let the comment inform NI that a better visual indication is needed when they actually come to implement it.

[donkdonk]

@tst. You are right.

[SteenSchmidt]

It could also be Bool-green plus signs (I actually like the plus-sign, as it both indicates "additional stuff" as well as is different from the typedef glyph):

/Steen

[Darin.K]

Ignoring the previous advice from tst, I Kudos precisely the previous picture.  Not literally precisely, but darned close.  It needs to be tweaked ever-so-slightly so it becomes a universal glyph.  By universal, I mean anytime a string, structure, array, etc. has "more than meets the eye" it should appear.  This means it may need to move slightly to become part of the array frame and permit a similar glyph for the string constant if needed.

[fabric]

Yep - the plus sign is good. I would even settle for a similar glyph applied to the borders of structures in my visual indication that a structure is hiding code beyond its boundary idea...