Change properties of a cluster element withing an array of clusters

[Kochise]

Hell Yamaeda, Oligarlicky, Jeff·Þ·Bohrer and altenbach.

Thanks for this last solution, while it is not the best option,

will require some refactoring to store the 'Conformité' message

outside the cluster array to replace it with a picture, it is still

the best and less work incentive alternative.

I will considerate this approach and develop a version from

it and will let you know if the result is satisfying enough for

my colleague.

David Koch

[Kochise · Accepted solution]

Hello,

I took a little moment to hack your solution

into my program, and here's what I get :

It's still rather strange that Excel, a simple spreadsheet

program, can change individual cell's color, but not a

powerful dataflow-based, graphical, programming

language such like Labview.

Anyway, that done the trick, solution adopted !

Kudos raining !

David Koch

[Hooovahh]

---

@Kochise wrote:

It's still rather strange that Excel, a simple spreadsheet

program, can change individual cell's color, but not a

powerful dataflow-based, graphical, programming

language such like Labview.

---

So I'm guessing you know this, but in that VI you aren't dealing with a table, like you are in Excel.  If you have a LabVIEW table you can change the cell color of each cell without affecting the other cells.  But what you have there is an array.  And an array contains elements, and the only thing allowed to change between the elements is the value.   There are several ways to get the behavior you want visually, but arrays cannot do it.

[Kochise]

Of course I know, but I'm still rather disappointed.

The array of elements 'should' ('could' ?) have

duplicated not only the data elements but also

the attributes elements to allow playing with

each of them individually, or allow bulk change

(like 'select column, change color')

What other choice have I had to chose between ?

David Koch

[Hooovahh]

---

@Kochise wrote:

What other choice have I had to chose between ?

---

I'm having a hard time finding the link now, but there was a demo where what was displayed to the user was a cluster not an array.  The cluster can have individual elements have different attributes of couse.  Then there was a vertical scrollbar that when it would change would change the data in the cluster, giving it the appearance of an array, but actually being a cluster.

It can be a lot of work, and I wanted to make some tools to make this easier, but depending on how particular you are about your UI you could give it a try.

Also if you are okay with the background color changing and the font staying the same color, you could hide a colorbox behind the string indicator, and set it to be transparent.  Then the value of this colorbox is the background of the string.  Sorta like this.

http://forums.ni.com/t5/LabVIEW/Coloring-elements-in-array-of-clusters/td-p/1992041

[David-A]

I'm a little late to the party here but nathand put together an excellent example a while back that demonstrates the table idea that hoovah mentioned. Its got a slick interface, and like hoovah pointed out you can modify the color of the text since its a table control not an array.

https://decibel.ni.com/content/docs/DOC-31269

[Kochise]

Thanks, but that looks like a lot of effort to tweak UI

appearance while an array of cluster should have

not linked attributes together.

I mean, you can loop through all the data and set them

to the same if you want. Or have data set individualy.

You might have been able to do the same with the

attributes of each cluster's element, loop through

all of them to set the same text font/color, or set it

on an individual fashion.

Perhaps using the same loop, with something

looking a lot like cluster bundling.

But not, instead all the attributes of a single cluster

are linked together, who knows why.

While Labview was supposed to help the 'technician'

to create color rich user interface, it just shows how

much it is far from reality, cumbersome, needlessly

overcomplicated to perform somewhat common

data presentation.

Am I a dreamer or just a grumpy old man expecting

something out of his software registration from a

well established software company ?

I'm fed up trying to tweak the language into something

it was finally neither engineered nor updated for.

Just look at my useless fighting with variant, supposed

to be the cornerstone of the G programming language,

the peak of evolution. You only get unsupported and

undocumented VI to play with instead (hidden VIs in

the VariantDataType folder)

My Labview and Teststand experience is far from

being satisfactory, I don't think any additional and

expensive NI courses would solve any of my issues

with them, as the problems are deeply rooted into

the products' functionality. Or lack thereof.

David Koch

[drjdpowell]

---

@Kochise wrote:

But not, instead all the attributes of a single cluster

are linked together, who knows why.

---

Though I'm with you on lamenting the lack of a suitable UI element in LabVIEW that easily does what you want, there is good reason why the current array control uses a single set of attributes.  It is much more overhead (performance and memory usage) to have independant attributes for each array element.   

[drjdpowell]

BTW, have you thought about just using a Cluster instead of an Array?   You can easily get an array of references to the cluster elements and thus update all their attributes individually.  The Cluster will be of fixed size, but you can hide (or disable-grey) unused subclusters.

[Kochise]

That argument, again.

We're not dealing with embedded development in

constrained environment. We're dealing about desktop

application with dataflow based graphic programming

language.

The operating system being mostly Windows based,

you already have to fit a handful stick of RAM just to

get the machine up and running.

Don't tell me that duplicating the String's attributes

(font, size, color) would be such a memory overhead.

I'd like we remain a bit professional and use sensed

arguments to defend our pitch.

David Koch