BundleMagic.llb

[littlesphaeroid]

LabVIEW Bundle Magic Plugin

Watch a video showing what BundleMagic can do.

Bundle Magic is a LabVIEW plugin that augments right-click menu options for manipulating by dialog:

• Cluster and class wires and terminals
• Unbundle- and bundle-by-name nodes
• Refnum terminals and wires
• Property and Invoke nodes
• Class constants and controls

A dialog is presented to search and select cluster items, properties, methods, and LabVIEW classes, automating the placement of bundle- and unbundle-by-name nodes, property nodes, and invoke nodes when clicking on the appropriate terminals or wires.

You can also add, remove, or rearrange elements from bundle- and unbundle-by-name nodes and property nodes;  browse and change methods on invoke nodes; and  select and apply class types for LabVIEW class constants. 

Zyga's Insert Bundle By Name was the primary inspiration for this plugin. That inserts one item at a time through a tree of flyout menus, and I saw in this an opportunity for improvement. I borrowed some code in order to learn how to get a data type from a wire. Thank you.

The code used to rearrange named un/bundle/unbundles while preserving wiring was modified from Alexander Sobolev's Drag Bundles Quick Drop called DragBundles, and corrects a bug there which does not always preserve wire branches during cluster rearrangement.

Function Overview

Block Diagram
Block Diagram Objects Affected	Right-Click Menu Options	Has Dialog?	Notes
Cluster Source Terminal Class Source Terminal	Bundle...	*Y
	Unbundle...	*Y
Cluster Sink Terminal Class Sink Terminal	Bundle...	*Y	Creates a constant if unwired and selected without a corresponding source terminal
	Unbundle...	*Y	Only allowed for wired sink terminals
Cluster Wires Class Wires	Bundle...	*Y	Inserts named bundler on wire
	Unbundle...	*Y	Inserts named unbundler on Wire
Unbundle By Name Element Terminals Bundle By Name Element Terminals	Add Elements...	Y	Click on a specific output terminal to add items before or after that terminal
	Remove Elements...	Y
	Remove Unwired Elements	N	If all elements are unwired, the last element will remain after this function executes
	Rearrange Elements...	Y	Change order of elements in un/bundler node
Refnum Terminals Refnum Wires	Drop Properties...	Y	Drop Property Node and connect to terminal or insert property terminal on wire
	Drop Method...	Y	Drop Invoke Node and connect to terminal or insert Invoke Node on wire
Property Node Element Terminals	Add Properties...	Y	Insets properties before or after the clicked property. If only the default element is displayed, this function will replace the default element
	Remove Properties...	Y	Select items to remove from the node
	Remove Unwired Properties	N
	Rearrange Properties...	Y	Change order and./or read/write of displayed properties in node. Setting R/W status of an element to false will remove the element from the node.
Invoke Node	Browse Methods...	Y	Set method of Invoke Node
Class Constant	Browse Classes...	Y	Change class of class constant
	Copy Class Name to Clipboard	N
Front Panel
Refnum Control	Browse Classes...	Y	Change class of refnum control

*Bundling or unbundling clusters with one terminal will occur without a dialog; Single element clusters where element is unnamed will drop an unnamed un/bundler node without a dialog unless terminal is a tunnel.

Outstanding Issues

Installation

Bundle Magic requires a patch to the LabVIEW core, so manual installation is not recommended. Use the supplied VI Package Manager installer.

Planned Improvements

Properties and Methods dialogs can be slow to load because they are built on the fly from a list of all available properties. Prebuild all properties and methods by data type.

Known Issues

• Deprecated Properties The Remove and Rearrange dialog will show all deprecated properties as both read- and write-available. This may not always be accurate. Thus, changing the R/W setting of a deprecated property in the rearrange dialog may not work.
• Placement of un/bundle nodes may be incorrect for sequence locals on stacked sequence structures.

Author: Russell Wagner, Little Sphaeroid Design

[tst]

Looks nice.

I haven't tried it yet, but a couple of suggestions:

1. Add which versions it supports.
2. Write exactly what patch it applies to the core and why that patch is there. I'm assuming it's this - https://forums.ni.com/t5/LabVIEW-Shortcut-Menu-Plug-Ins/Bug-Fix-for-ALL-Right-Click-Menu-Plug-Ins-LV...

[tst]

OK, now that I looked at this a bit more, I am impressed with the amount of work. One thing specifically I was looking at, after I saw you said you can insert properties, was whether this supports properties for nested objects, and I was surprised to see that it did. I went spelunking inside to find out how you did it, and while it's convoluted, the important thing is that it works and I don't think there is any more practical way of doing it.

For those wondering, the basic idea is to start with a VI with a class specifier constant and a couple of property nodes chained from it, get the classes from the constant, make a tree out of them and then iterate over that, set the constant to the specific class and set the first property node to each of the properties. If the data type of a property is a refnum, then check the second property node to get the dotted properties. Then save all of that, so that it's cached.

A couple of feature requests:

1. Allow replacing a property, not just inserting. Basically what this plugin was doing, except done properly with dotted properties.
2. Change the filter to work like what the plugin I linked to does, where you can type more than one search term. Basically, just change the search code in LSD_Tree_Filter_1 Text Filter.vi
3. Add a move up and move down options to the top level menu, like this plugin. It's already a bit crowded, but often that's the action I want to do and it would be nice not to have to go through a dialog.

[felipe.foz]

Very interesting plugin and useful. Congrats.

I noticed it works with OOP as well.

Although I noticed the plugin is about 7 MB, is this correct?  Does anyone know if it impacts on LV Performance? Or is it ok after compiling?

Regards,

[AristosQueue (NI)]

---

felipe.foz wrote:

Although I noticed the plugin is about 7 MB, is this correct? Does anyone know if it impacts on LV Performance? Or is it ok after compiling?

---

I have not investigated this particular LLB, but I wouldn't worry. The design of the right-click framework is such that only the builder VI loads to build the menu. These are typically very small, single VIs. The bulk of any of the LLBs is the execution VI, which is only loaded if/when you actually pick that menu item. I have some fairly complex builder VIs shipping with LV -- see the channel endpoint creation menu items, if you're interested -- and we are still quite far away from breaking the 10th of a second response time between right-click and menu appearance that is what humans tolerate.

As long as the developer of the LLB turned on source-only on all the VIs in the LLB, you should be fine after the first right-click. If they did not turn on the source-only setting in VI Properties, then you could have a recompile hiccup on every right click that includes that menu item. As a general note, I strongly recommend that everyone except TestStand (ab)users* turn on source-only settings on all existing VIs and enable the Tools>>Options setting to turn it on for all future VIs.

* By which I mean the people who want TestStand to load loose VIs (i.e. VIs not built into a PPL or DLL) into the run-time engine (instead of calling the IDE). It's a seriously problematic model of operation for LV, but it is very common among TestStand users.

[felipe.foz]

---

@AristosQueue wrote:

I have not investigated this particular LLB, but I wouldn't worry. The design of the right-click framework is such that only the builder VI loads to build the menu.

---

Thanks for the reply.

---

As long as the developer of the LLB turned on source-only on all the VIs in the LLB, you should be fine after the first right-click. If they did not turn on the source-only setting in VI Properties, then you could have a recompile hiccup on every right click that includes that menu item.

---

That was I thought originally. I didn't check about this option inside the llb either, but it appears to be very responsive after the first click.

[Eric_BOB]

Hi. Thanks you very much for this magic tool. Impressive work.

I have just find one small bug. When i try to Bundle or unbundle cluster with one  Class as element in another place than first , your tool always create first element (AK.Bool). However the class is correctly display in dialogbox and correctly select i think.

It's not very critic bug, but better without.

Thanks again

Eric

[code-lux]

Hi Russell,

thanks for that powerfull tool! 😀

Unfortunately I do get a reproducible LabVIEW crash 😖 when I use the Insert Elements... on an already wired bundle node of an actor class.

Im using LabVIEW 2020 32bit on Windows 10 Enterprise 64bit

Crash Info:

Similar crash when using Remove Elements...

When using Insert Elements... on an already wired bundle node of a simple class then nothing happens for a few times and then still a crash:

Remove Elements... works on simple class.

Remove Unwired Elements always works.

Do others have similar problems?

Is this a LabVIEW bug or a bug in this Plug-In?

Thanks & Regards,

Luxamor

[AristosQueue (NI)]

code-lux: The fact that it is crashing means it is a LabVIEW problem. As I've said often over the years, the only two sources of LV crashes that are not LabVIEW's fault are calling external code (Call Library Node, .NET nodes, etc) or the Type Cast primitive casting refnums (you lie about data types, there's not much LV can do to check it until it is way too late!). 

I'll flag a tech support engineer to replicate your bug report and get it filed to R&D to investigate.

[code-lux]

Meanwhile I found out a main cause of the problem: I had a control in the class private data that contained a point (.) in its name.

I noticed that Bundle... and Unbundle... would not work as soon as I included that control with the point.

Now that I removed that point (.) I do not get imediate crashes anymore - but Insert Elements... still does not work and eventually causes a crash (like discribed above for simple class).

[Darren]

I added a "Request Deallocation" function to the block diagram of the "LSD_Get All Properties_3.vi" and the crash went away. Not sure why the 'Insert Elements' menu option is no-opping but that's likely something that will need to be debugged in the plugin scripting code.

[Petru_Tarabuta]

Thanks for a very useful tool! I've been using it for a few months and am impressed with how useful and polished it is.

[TeraTech]

One of my favorite plug-ins!  I discovered one "quirk" that I'm not sure is a bug or if it's functioning as designed. The "Remove Unwired Elements" also removes elements with broken wires. Personally, I would prefer that connections to wires with errors remain, just as in the "Remove Unused Terminals" plug-in https://forums.ni.com/t5/LabVIEW-Shortcut-Menu-Plug-Ins/Remove-unused-terminals-llb/ta-p/3517977. Also, just a cosmetic comment - shouldn't there be a divided after the last item, "Rearrange Elements..." ?

[JoGra]

I added a "Request Deallocation" function to the block diagram of the "LSD_Get All Properties_3.vi" and the crash went away. Not sure why the 'Insert Elements' menu option is no-opping but that's likely something that will need to be debugged in the plugin scripting code.

---

The "Insert Elements" for a class is not opening because the "Get Cluster Information.vi" in "LSD_Traverse_Cluster.vi" cannot access the private data and the returned array of cluster elements is empty. 

There is surely someway of getting the private data elements with vi scripting and adding a cluster/class check there. 

[Darren]

> There is surely someway of getting the private data elements with vi scripting and adding a cluster/class check there. 

Not really. There are some complicated approaches I've seen some people take, but the whole point of it being private data is that it's private.

[wiebe@CARYA]

>> There is surely someway of getting the private data elements with vi scripting and adding a cluster/class check there. 

>Not really. There are some complicated approaches I've seen some people take, but the whole point of it being private data is that it's private.

However, not having access to the private data makes it impossible to e.g. serialize the data, without violating the single responsibility principle. It's quite a pickle.

Getting the private data elements isn't that hard (hint: myclass.lvclass has a control myclass.ctl). Esp. in development simply getting the controls, the first is the cluster, and use controls again, works OK. In an exe, you can't use that, but Get Controls By Index still works, unless the cluster is empty (then it's very slow)... Of course you have to traverse all parents.

Flattening (to JSON, to XML) only works when the data isn't default...