The minimum size of classic framless colorboxes should be two, not five

[altenbach]

I sometimes use arrays of classic frameless colorboxes to quickly display a color table.

Unfortunately, the minimum size of these elements is 5 pixels :(, making a 256 element color ramp 1280+pixels wide, showing redundant information in 5 adacent pixel columns each.  If we display the color ramp vertically, it would not even fully fit on a common 1080p display!

This makes it too wide to correctly display them in the forum and forces a size reduction that makes all other text and diagram code illegible.

(Yes, we can right-click...open image in new tab, and click the image to display it 1:1 (in chrome), but that's more work and not everybody knows that)

It would be perfectly OK if we could make these elements only 2 pixels wide (or high), making the array display a much more reasonable 512 pixels and keeping the front panel to a more reasonable size.

Idea summary:

The minimum size of the classic colorbox (frameless) should be 2x2 pixels (or even 1x1?) Currently it is 5x5, i.e. too big.

[AristosQueue (NI)]

Jannis:

The code you've written is why LV probably hasn't bothered to create such a control before now. It's a fine way to do it most of the time. BUT the code you've written is slow by comparison to the rendering speed of the 2D array. There's a lot more memory allocation, which can matter significantly for a large 2D image. What it does is copy the data into the pixmap cluster, then create a string that contains that cluster, then parse that string to render the image, then render the image.

Also, you're missing the first transform from 2D array to 1D array.

[Jannis]

Yepp, I was wondering how much overhead there actually is in using the PictureControl! Now I might consider using the Matt_McLaughlin-Array instead for image displaying. Missing the extra feature of being able to draw on top of it of course. Unless I'm also faster in creating the overlays myself? - The Matt_McLaughlin-Array is a 2D array also. So there is no difference.

[altenbach]

Thanks for the small colorbox!

> building the Boolean is not so easy -- there's chrome on the Bools that would need to be modified. More than just a few minutes of work that the color box took.

I just noticed that the size restriction is less in the control editor. I can actually create a 1x1 or 2x2 "classic flat square button" or "classic colorbox"!!!

If I try to resize on the front panel using the "set width and height" tool, the size coerces up to 5 pixels. However if I use the same tool in the control editor, I can get down to 1x1!

Here's a 1x1 classic flat square button!

Still, the idea would be to lift the limitations also while in the VI editor, so it should probably stay. However, there's a good workaround. 😄

[AristosQueue (NI)]

Neat. At this point, I'll ask Darren to close this idea as Already In LabVIEW.

[altenbach]

Thanks! It was somewhat surprising that the same "Resize Objects" tool has different restrictions depending on where it is called (VI editor or control editor). Who would have thought? 😮

Obviously it is trying to protect the user from making extreme choices, but maybe the restriction should be lifted also in the vi editor. Typically, the users knows best. 🙂

[Darren]

Already possible in LabVIEW today. See discussion thread for more details.