Macro in LabVIEW

[cyro]

I'm missing the feature of using macros in LabVIEW like in other languages. In text-based

languages a macro is a text replacement before compilation so in LabVIEW it should do the

same with g code.
I don't like the idea to put every single code into a sub VI just to clean up the code.

There are enough reasons to create sub VIs but the goal is to build logical / programmatical

units.

 

Consider a situation you are using long text in string constants enlarging the whole code

through this.

Consider a situation you are using many property-nodes within a while loop.

Use macros to avoid this.

 

So how to implement?

 

Macros are unique in every VI. Every VI should have named extra block-diagram layers to define these macros, one layer per macro. These layers are similar to a standard VI except they don't need / use a front panel to connect the controls. All controls are connected within the macro block diagram. The macro is used like a standard VI. It has a icon like a standard VI and is placed on the block diagram like a standard VI.

The macro code will be embedded virtual before compilation so the code will not be touched.

That's it - I think 🙂

[Intaris]

Having used IDEs from text-based languages I find the ability to collapse code to be very useful.

Something of this sort for LabVIEW would be great.  ActiveX calls, Property nodes and the like could just be collapsed and given a label.  Giving a label or description is important so that we know at a glance WHAT has been collapsed.  Sub-VIs are great and all but as soon as control references are in use, sub-VIs get a lot less attractive.

But hasn't this been suggested before and what's the difference between this and a macro?

[cyro]

Here are some examples...

Example 1:

Example 2:

[tst]

I consider those to be legitimate places to use a subVI. You would have to create the icon and connections anyway, so the only thing you gain is not having another file. And this advantage will only hold as long as you don't need this piece of code in another VI.

Shane's example of ActiveX/.NET is better. I've done those as well and while sometimes subVIs make sense (you can create them based on original class hierarchy), being able to collapse such code in a single VI also has an appeal.

[cyro]

I don't like to create a SubVI only for a single VI like "I16 to String" but this the normal way to cleanup the code. In my opinion SubVIs shouldn't be used to do cosmetic cleanups like this but I think this is only my point of view.

Thanks for the discussion 🙂

[Intaris]

I agree with Tst, I think these examples are perfect for sub-VIs.

I still maintain it would be useful for certain code types to be able to collapse though.

[G-Money]

I agree that using subVIs is proper in these places but also agree with cyro that adding extra code just for readability adds to the overhead. Luckily inline subVIs were added in LabVIEW 2010 so you can encapsulate your code in a subVI but not incur the extra overhead from calling the subVI. Try this functionality out but I think it will solve the functionality you are looking for with your macro idea.

[InfiniteNothing]

The way I think about this feature is that it's a really fast way to expand/hide bulky parts of one time use code like large string constants, large cluster constants, front panel initalization code, unbundle arrays, etc.

I think there's strong parallels to the + and - icons in text editors where you can hide entire if/then statements. Arguing that the developer should use a subVI is like saying in the the text programming world that the developer should have to make another function in another file.

Keeping the parallelism, I think macros should work on a per structure basis. The feature would be very much like the sequence structure hack but be much easier to access and edit with the code expanding in a new window and then colapsed back down to the structure.

I don't agree with this sentiment:

 I am hesitant to support this idea because I think this is a feature that would be abused too easily

  I think that's like saying we should ban the build array because some people write memory leaks.

[ijustlovemath]

One point that the OP did not mention is the use of macros to create classless, reusable, type-insensitive code. For example, let's say you wanted to write code to, given an arbitrary cluster, return the default value of said cluster, without using anything from VariantType.lvlib (password protected diagrams don't sit well with me). The obvious first choice is to do something like this:

It's a common design pattern to pass an enum alongside variants we use as arbitrary data containers, but what if the need for such a setup was not needed because of the language itself?

We commonly like to think about how to modularize such code, but if you have a variant and you know what's in it, you still need to write one variant-to-data subvi for each possible cluster, typedef, control, or what-have-you that you encounter.

Unlike most LV constructs, macros wouldn't care about the type, and would merely exist as type-independent code frameworks you could drop in wherever you like.

It's a very similar concept to the actor framework, which aims to abstract away common coding constructs like the QMH that are still tied to the data they pass, unless you have put a lot of thought into the design ahead of time.

[AristosQueue (NI)]

Implemented in LV 2017, enhancement coming in 2017 SP1. See help for "Malleable VIs".

[Darren]

Available in LabVIEW 2017 and later with the 'Malleable VIs' feature.