Joerg Hampel is a guest blogger. As the owner of Hampel Software Engineering, CLA, and LabVIEW Champion, his biggest interest lies in team development best practices.
This post was originally published on hampel-soft.com.

Using LabVIEW’s VI Scripting features, it is surprisingly easy to create tools that increase development efficiency and enforce coding guidelines. For example, having groups of associated VIs stand out on your block diagrams makes maintenance a lot easier. VI Scripting allows you to add glyphs to VI icons programmatically with very little overhead.

Adding a glyph to a VI icon manually

Adding a glyph to a VI icon manually


Manually adding a glyph to a VI isn’t too much of a hassle. You create your new VI or open an existing one, you fire up the Icon Editor, you design your artwork, you do or do not add a glyph. All is well. But imagine having to add the same glyph again and again to new VIs, or tidying up legacy code and having to deal with a large number of VIs – quite soon this becomes a tedious piece of work.

Automate tedious recurring tasks

With VI Scripting, we can automate this cumbersome recurring task. The LabVIEW Icon API – which is easily accessible through the Hidden Gems in vi.lib – comes with everything we need to access a VI’s icon programmatically and read or write layers.

LabVIEW Icon API – Hidden Gem palette

LabVIEW Icon API – Hidden Gem palette


With a little digging into the contents of the vi.lib/LabVIEW Icon API/ directory, we quickly find another API for creating or updating Layer data.
LabVIEW Icon API – Layer Class

LabVIEW Icon API – Layer Class


And this is really it:

  • Open a VI reference
  • Read its icon layers
  • Add a new layer with the glyph in it
  • Write back the VI icon
  • Save the VI

Done and dusted. See for yourself:

Block diagram for adding a picture to a VI icon

Block diagram for adding a picture to a VI icon


You can find the Add Picture to VI Icon.vi in our public HSE Scripting Tools repository on GitLab.

DQMH broadcast VIs

What’s the real-world application, you ask? What problem triggered this whole effort? Here goes:
The DQMH framework features broadcast events as a one-to-many way for any given module to tell the world that “something happened”. It comes with a handful of standard events for each module, and you can add your own. Each broadcast event comes with an auto-generated VI that you can use to send your broadcast message from your module to any external code registered to that broadcast event.
When working on or debugging DQMH modules, I like these broadcast VIs to stand out, so I can easily distinguish between simple subVIs (actions internal to the module) and VIs that interact with the outer world.

DQMH broadcast VI in action

DQMH broadcast VI in action


In order to achieve this blissful state of code, I have to modify each broadcast VI’s icon and – to conform with our coding style guide – add a glyph that symbolizes the broadcast. (Again, you can find the glyph file on GitLab in our public HSE Little Helpers repository).

Delacor to the rescue!

Reworking the default broadcast VIs is tedious, and reworking existing code that wasn’t built in accordance with our own style guide, or legacy code, or code from customers, is tedious no less. Even with our shiny new scripting tool, we still need to manually invoke that VI every time.
But thankfully, Delacor’s dedication to the community is second to none. There’s a place on the NI forums where Fab and her team collect feature requests, which allows for direct feedback from actual users of their product. I posted my request there (being a DQMH Trusted Advisor probably didn’t hurt, either), and I have it on good authority that one of the next releases will include this feature! Make sure to sign up for their newsletter to get your hands on it ASAP.
Awesome – thanks, guys!