Array of XControls ...

[manu.NET]

For the moment, the XControls can only be used one by one, on a front panel ...

It should be nice to be able to create XControls arrays ... in order to create "funky" listviews ...

=> Would give the ability to edit/view a collection of clusters, using an appropriate editor.

Manu.

[JackDunaway]

Actually tried to do this yesterday for the first time in a while - even tried the "drop it in a cluster, and drop that cluster in an array" trick (that works for graphs and charts) and it didn't work either. I have had to nix design concepts before (like yesterday's) due to the lack of this feature.

[Ramanajan]

Just spent a day building an X Control to use in this way and was annoyed to see this was not supported.

[X.]

ditto.

What is NI's answer on this?

Maybe rebaptize them "XControlThatYouCantNestIntoArrayOrCluster"?

[AristosQueue (NI)]

NI's answer on this is that XControls cannot be put into clusters and arrays and never will be able to because they weren't designed to be able to. We're going to have to deprecate XControls entirely and create something brand new that can be hosted like that -- this brand new thing will have to have an entirely different approach to control rendering than the existing Facade VI because in order to be a part of an array, you have to be able to make certain display guarantees that the existing XControl cannot make... for example, not doing any asynchronous rendering.

When XControls were written, we thought we were creating controls for use on end user displays -- it was a feature created to enable a new generation of richer UI elements. Well, we didn't expect arrays and clusters to ever show up on an end user display -- array controls suck for interaction and they're really limited in display... clusters we expected had to be unpackaged and distributed around on a panel to be usable. The typedef that you use for the code would never be the same typedef you would use on the UI... or so the thinking went. Because this was for polished UIs and arrays and clusters were not for polished UIs and because the API we would have to impose on our users was MUCH more intricate if these were going to be in arrays and clusters (particularly arrays), we didn't consider the feature to be a priority.

Turns out people do put array controls on end user displays. Turns out people want to build XControls for types that they want to have better displays for even on their low-level subVIs, not just on the polished panels. This is a case of us completely missing the use cases and the design environment. Back then -- 2003 -- our customer feedback systems were a lot less complete.

[X.]

Thansk for the detailed answer. It remains that it might save people a bit of frustration if all NI-authored examples for XControls started with the disclaimer: IF YOU ARE PLANNING TO INCORPORATE XCONTROL IN ARRAYS OR CLUSTERS, STOP AND DON'T READ ANY FURTHER. XCONTROLS CAN'T DO THAT.

Luckily, most people will probably start with something relatively simple. I just happen not to... And in hindsight, I may have already faced this issue in the past. Oh well.

And the link, I know well: I commented on it a couple of years ago, and it is one of the "NI-authored" examples I am referring to above. I was trying to understand the "do not bog down your facade VI with you animations" comment in the code, which I suppose you are pointing at. Would spawning different clones of a rendering VI be such an issue?

[AristosQueue (NI)]

It isn't about spawning clones... there aren't any clones in an array control -- there's just one control that is rendered in each position with a different value each time. That's why you cannot set individual properties for the elements of an array... the cost of creating N controls on the fly for a 100000 element array would be exorbitant and even just having N controls where N is the number visible is problematic as you change the array display index -- you'd need a way to tell one "ok, now stop what you're doing and pick up where the other one left off", and that's assuming you're ok with them not keeping up while in the background.

[X.]

So essentially this suggestion should be labeled "Declined", I suppose.

As a side note, the reason why I was trying to create an array of XControls, is, not suprisingly, because of another limitation (in my hands) of LV: namely the difficulty to align arrays of basic building blocks such as Numerics with respect to other objects (such as a Graph Legend for instance). See this suggestion which I visited shortly after fighting vainly with pixel-level alignment issues with an array of clusters...

I managed to design a compact XControl with what I thought was a neat UI idea, and which I was hoping to squeeze neatly in an array, with plenty of pixels to spare in case of unforeseen space doubling, but eventually, I had to drop a few independent copies of my XControl and "array" them manually (fortunately, there is a finite number of XControls I have to deal with, which I now have to deal with as an array of references. It is manageable, and even if the "array" size became dynamic, it would still be possible to juggle with refresh and data buffering using a fake scrollbar of some kind.

Maybe an idea for a future Example?

[AristosQueue (NI)]

No. It is useful insofar as it reminds us that this is a standing request from our users -- custom controls that can be hosted in arrays and clusters. And, as with many, it is one that research is proceeding on. When we get to the point that we think we have a model that could actually work, an idea like this would be moved to In Work. Until then, it remains -- a burr under the sadle, if you will.

[X.]

I wonder who is most annoyed in the "burr under the saddle" situation: the rider or the horse?

[AristosQueue (NI)]

At the size of burr we're talking about, it's mutual. Only difference is the horse gets more vocal as it believes the rider is capable of doing something about it.