Fix the type definition cluster movement bug

[strait]

I use a cluster as the element data type for a queue-based state machine. So, I have constants of my cluster type definition scattered throughout the block diagram. Whenever I update the type definition and Apply Changes, my cluster constants resize and even move around automatically (regardless of the AutoSizing selection). This is annoying and makes things hard to read unless I dedicate time to fix their size/position and the wires. Please fix this bug!

[Ahmed99]

Hello Can you  send me your code to solve it

[altenbach]

(Your post is a bug report, not an idea for a new LabVIEW feature and thus got moved here. It did not belong in the ideas exchange).

Please supply sufficient information (such as example code), steps to reproduce and of course state your LabVIEW version. You can post a quick link to this discussion in the annual bug thread.

[billko]

---

@strait wrote:

I use a cluster as the element data type for a queue-based state machine. So, I have constants of my cluster type definition scattered throughout the block diagram. Whenever I update the type definition and Apply Changes, my cluster constants resize and even move around automatically (regardless of the AutoSizing selection). This is annoying and makes things hard to read unless I dedicate time to fix their size/position and the wires. Please fix this bug!

---

Have you tried showing them as icons instead?  It saves a lot of space.

[Bob_Schor]

Yes, I totally agree with @billko.  When I first read your Post, I didn't understand the nature of your problem, but that was because ever since NI allowed you to make an Icon for TypeDefs, and have certain Icons replace the TypeDef on the Block Diagram (Cluster Icons, fortunately, are one of these), I always (usually Quick-)drop the Cluster Definition (big and bloated) on the Block Diagram, right-click the edge to "Iconify" it (it's now about 36 x 36 pixels), and use it.  Of course, you need to make an Icon for your Cluster TypeDef, but it certainly (a) makes your code more "readable", (b) saves it from "Bloat" when your Cluster TypeDef is large, and (c) spares you from having to change anything on the Block Diagram if you simply update the Cluster.  You do, of course, need to handle the changes you made when you use the cluster, but if you right-click on the TypeDef and do a Find All Instances, you should be able to do the (I hope small amount) of rewiring to accomodate the new Definition.

Bob Schor

[altenbach]

There are definitely cosmetic problems with clusters and type definitions.

For example if you have a diagram constant of a simple cluster where the elements show the labels and right-click and make it a type def, the labels get hidden and if I show them again, they are not in the original location! Why can't it retain the visuals of the original??? Note that auto-sizing is still checked, but not actually applied until we do it once more.

Showing clusters as icon is nice and all, but sometimes I do have huge typedef cluster constants and need to change the value (e.g. if they are used to initialize a shift register and I want a new default value for one of the items), I need to show them fully (i.e. not as icons!), at least temporary. No way around that.

[billko]

---

@altenbach wrote:

There are definitely cosmetic problems with clusters and type definitions.

For example if you have a diagram constant of a simple cluster where the elements show the labels and right-click and make it a type def, the labels get hidden and if I show them again, they are not in the original location! Why can't it retain the visuals of the original??? Note that auto-sizing is still checked, but not actually applied until we do it once more.

Showing clusters as icon is nice and all, but sometimes I do have huge typedef cluster constants and need to change the value (e.g. if they are used to initialize a shift register and I want a new default value for one of the items), I need to show them fully (i.e. not as icons!), at least temporary. No way around that.

---

I thought it was not recommended to rely on setting default values in cluster constants because they may revert if the typedef changes.  My recollection is that it was safer to explicitly bundle the desired value.

[altenbach]

---

@billko wrote:
I thought it was not recommended to rely on setting default values in cluster constants because they may revert if the typedef changes.  My recollection is that it was safer to explicitly bundle the desired value.

---

Well, that's a different discussion and should not distract from the cosmetic problems discussed. 😄

(I usually proceed carefully. My cluster typdefs are quite static and typically not edited later in development. If I ever add an item, it is added at the end, i.e. no reordering or messing with (e.g. renaming) existing items. Items that are no longer needed are left in place).

[billko]

---

@altenbach wrote:

---

@billko wrote:
I thought it was not recommended to rely on setting default values in cluster constants because they may revert if the typedef changes.  My recollection is that it was safer to explicitly bundle the desired value.

---

Well, that's a different discussion and should not distract from the cosmetic problems discussed. 😄

(I usually proceed carefully. My cluster typdefs are quite static and typically not edited later in development. If I ever add an item, it is added at the end, i.e. no reordering or messing with (e.g. renaming) existing items. Items that are no longer needed are left in place).

---

That is, indeed, practicing safe typedef'ing.

[strait]

Hello Billko et al.,

I have been using a type def cluster for a queued state machine with code such as this:

Here, the cluster contains just an enum (the state) and an auxiliary numeric value. I've been displaying the contents of the cluster because then I can immediately read off the state I'm adding to the queue. (As an aside, I'm not sure whether this is a best-practice architecture, but it's working okay for me.)

The problem is that when I change the elements of the enum in the type definition and apply changes, things get resized, which also changes the center position of the cluster such that over several changes, the cluster can "walk around".

Here, size-to-fit is selected on each cluster constant:

 Here, autosizing is None:

This is annoying! It doesn't affect the performance, only the aesthetics and readability.

Now, I may take the suggestion to use icons instead. The downside is that I won't be able to read the state I'm queuing, so perhaps a workaround is to contain this information in the label like this:

But is this really necessary? When updating a cluster type def, LabVIEW should just leave the displayed constants alone to the extent possible.