Scripting the In Place structure, how to grow a cluster bundler

[littlesphaeroid]

When scripting a named bundler or unbundler, adding elements tot eh node can be done two ways: The methods "AddInputAfter" or "AddOutputAfter", and "Resize:AddChunk" (with argument to add elements to top or bottom).

The cluster unbundler on an in-place structure, in contrast, offers the method AddOutputAfter, but the "Resize" method is not the same. There are no arguments, and the help indicates that it literally resizes (in pixel dimensions) the bundle node. I think it does not do this, as resizing this node in this way is not possible.

So, while I can programatically insert elements before the first element on a named un/bundler, it appears I cannot do this with the similar node on the in-place structure. 

Any suggestions for a workaround? I could add the items to the end and then rearrange, which requires some rewiring of the existing terminal (more code, but doable).

[littlesphaeroid · Accepted solution]

I have created the required workaround code (attached) to get around the invoke node bug for the in-place element structure.

[wiebe@CARYA]

---

@littlesphaeroid wrote:

I think it does not do this, as resizing this node in this way is not possible.

---

It does do exactly this!

The size you set it to has to be a multiple of "Terminal Height". The terminal height is 17 on my system, and Resize does resize the unbundle if I specify 17, 34 or 51. Note that it will resize to 4 unbundles, even if there are less variables available.

So, it's not a bug. The functionality that you are looking for is simply not provided...

[littlesphaeroid]

I consider this a bug, since this is not what "size" means in any other LabVIEW context; In no other case do you add terminals to a growable structure by setting the node's height. But I do very much appreciate your workaround!! 🙂

[wiebe@CARYA]

---

@littlesphaeroid wrote:

I consider this a bug, since this is not what "size" means in any other LabVIEW context; In no other case do you add terminals to a growable structure by setting the node's height. 

---

The method does what it's supposed to do. (What it is supposed to do is not documented, so even if it doesn't, there's plausible deniability.) There is no rule that methods of other growable objects have to be available for all growable objects. With scripting, there are no rules at all.

The behavior is (almost by definition) intentional behavior, and therefore not a bug AFAIC. Pretty sure NI will agree.

Inconvenient, that it is...

Room for improvement? Sure.

[littlesphaeroid]

Frankly, your assertion is absurd. If growing a growable function were anywhere else in LabVIEW achieved by setting its height in multiples of the terminal heights, I would agree. The fact that this is done correctly on similar nodes (eg, bundle by name), and that setting and object's height in every other context I've found actually works in one-pixel increments, indicates that this was a shortcut or oversight. 

[wiebe@CARYA]

---

@littlesphaeroid wrote:

Frankly, your assertion is absurd. If growing a growable function were anywhere else in LabVIEW achieved by setting its height in multiples of the terminal heights, I would agree. The fact that this is done correctly on similar nodes (eg, bundle by name), and that setting and object's height in every other context I've found actually works in one-pixel increments, indicates that this was a shortcut or oversight. 

---

I'm not saying it isn't a shortcut or oversight. Just that it isn't a bug.

If you insist that it is a bug, report it as such. I don't think they'll accept it as bug, but they might still fix it.