Allow small icons for type Def.

[pylb]

A VI's icon can be made of any shape by not filling all the pixels in the icon editor. A cluster constant can be displayed as a small icon. But a cluster constant which is connected to a type def. will display a full size icon no matter what. Why not allow transparency for type def icons?

[AristosQueue (NI)]

The following is just my opinion as a user... not speaking for NI on this one...

We have to be careful here, I think. I do not want to be reading a diagram and mistake a typedef constant for a subVI calls. In some ways, it would be ok if a typedef constant was mistaken for a subVI call since I can think of it as a node that outputs one value, but the way that I as a user interact with a diagram constant is very different than the way I interact with a subVI node -- for example, two identical subVI nodes do the same algorithm, so if I copy from one diagram to another, it doesn't matter which one I select, but a two diagram constants have different values, so it matters which one I copy. Given that and other differences, it seems reasonable to me to say they should be visually differentiated.

Given that, I could see LV shrinking the border down around the icon... something like this, perhaps:

but I wouldn't want to see the border disappear entirely.

[pylb]

I am fine with the border, it is a good idea actually. I agree that constant and sub-vi are 2 different things that need to be differentiate. My point was that there is no reason for a type def to take so much space.

[Wart]

Why not allow either the current type def icon or a shrunk icon that matches the current cluster (non type def) constant with the addition of the grey triangle in the corner?

The users View As Icon option settings could determine which view shows up as the default.  That way people might not be as encouged to make less useful VI icons just to take up less room on the block diagram.

[pylb]

I just find out that NI already does this for their own type def, like the annotation type def for graphs, LVAnnotationListTypeDef.ctl. (Which, BTW, has a generic icon)

[JackDunaway]

---

@pylb wrote:

I just find out that NI already does this for their own type def, like the annotation type def for graphs, LVAnnotationListTypeDef.ctl. (Which, BTW, has a generic icon)

---

That's not quite what's going on here. Note that the typedef is an array of clusters, not the preferred array of typedef'd clusters. That's why the cluster appears with the "generic" glyph.

---

@aq wrote:

Given that, I could see LV shrinking the border down around the icon... something like this, perhaps:

but I wouldn't want to see the border disappear entirely. 

---

 Agreed to not get rid of the border - that shrinking border idea looks good!

[Neil.Pate]

<sort of thread hijack!>

How many people use glyphs for their typedef icons?

I know NI recommends NOT using words, but when you have dozens or hundreds of typedefs in a project (not uncommon) it is just not realistic to have a different icon describing each one properly.

</end of thread hijack>

Normally I have two or three lines of text, and that fits in quite nicely with the current size. I do not like the idea of each typedef having a different physical size on the BD, I think it would look messier not neater. How many pixels are we really going to gain here?

[A-T-R]

Very good point, nrp!