LabVIEW Class And Cluster Unbundle Bundle With IPE.llb

[AristosQueue (NI)]

Author: AristosQueue (NI)

This plug-in makes it easy to an an In Place Element structure for unbundling/rebundling clusters and LabVIEW classes. You right click on a terminal of cluster or class type. The new menu item is added under the Create menu. For LabVIEW classes, the option only appears when you are in a member VI of the class (because non-member VIs are not allowed to unbundle class data).

The terminal does not have to be wired but it can be. This does a create on a branch. It does not insert the IPE into the wire.

If you like this, you may also want this related plug-in which does the same thing but works on wires and does Insert behavior.

Before:

After:

Attachement is saved in LabVIEW 2015. For install instructions, go here.

[vishots.com]

Is there a reason why this is inconveniently on a branch instead of the more convenient insert?

[AristosQueue (NI)]

I have needed both models, but I didn't want to add some sort of dialog to pick which one. It seemed to me to be easier to rewire for the insert case when I needed it than to unwire for the branch case when I needed that.

You think I should default the other way?

[Beutlich]

Could you comment on the use cases/distinction between the two? I would've defaulted pass through also, because it ensures whatever you connect to the wire out is the same data space, whereas connecting to the wire before may or may not be a copy of the class data, and knowing if there is a copy or not is hard to guess from just the wiring (and I probably care about data spaces since I'm using the IPE and not just a bundle/unbundle).

[AristosQueue (NI)]

When I fork a class wire, I intend to make a copy. Whether or not LV actually makes a copy is a matter for it to decide inside the compiler. I don't care when the copy gets made, so long as from my point of view, it happens at the fork.

The fact that I am forking means it is my intention to modify a separate copy of the object. This occurs when I am going to modify some of the fields but I need to be able to support Undo or transaction rollback -- where I'll have to put the original object back into play later if the transaction fails or the user chooses Undo. I may still have reason to use the IPE structure for this separate modification, especially if the modification is incrementing some existing field or something like that.

[smithd]

I would agree with the others that the default should be inline. I've done what you're suggesting with a transaction-like behavior, but rarely do I do that at the same level as the IPE. Usually the IPE would be within a subVI, while the calling code is responsible for the transaction.

[AristosQueue (NI)]

I do both with equal regularity, but I'm happy to adjust the behavior for this plug-in if there's a clear bias across the wider user base. I'll try to get it done this afternoon.

[AristosQueue (NI)]

Had an idea...

what if I leave this plug-in unchanged -- you popup on a terminal, you get "Create" behavior, which adds a branch (just like if you had done Create Indicator).

But then I create a second plug-in that works on wires and goes into the Insert menu. "Insert Bundle\Unbundle In-place Element Structure".

Would that be a good way to split the difference?

[Craig_]

That sounds like a solution that services both needs!

[smithd]

Works for me, and then you'll have a better measurement of what people prefer as well.

[AristosQueue (NI)]

I posted the new inserting plug-in here:

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