From 11:00 PM CST Friday, Feb 14th - 6:30 PM CST Saturday, Feb 15th, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
From 11:00 PM CST Friday, Feb 14th - 6:30 PM CST Saturday, Feb 15th, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
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.
Is there a reason why this is inconveniently on a branch instead of the more convenient insert?
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?
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).
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.
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.
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.
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?
That sounds like a solution that services both needs!
Works for me, and then you'll have a better measurement of what people prefer as well.
I posted the new inserting plug-in here: