X___

That's what I mean: I think it should be a LabVIEW primitive for built-in types. There is no error passing so if the input variant if of the wrong type, you get the default type, but that's fine for my purpose. I am supposed to know what I am doing when I lay down my wires, right?

You are reinventing variant attributes and the corresponding primitives (see my post above). This being said, there is a lot of things to be commented on your code from a G-style point of view :-) but I'll leave that to others. As far as wrapping the Variant to Data primitive into a polymorphic VI, see my comment above as well. A nicety, but is this really worth the hassle? I have done that myself for a few common types (numerics, string, path, and array of such) and I find that very handy, but I wouldn't bother for types I use occasionally, and in particular, application-specific types. Just my opinion.

Maybe the OP is trying to achieve a generic storage container (functional global of sort) using a variant. Something akin to this: Here I am using a typedef enum (Variable) to ask for a specific item, which is stored as an attribute of a single variant. There is no need to use a DVR to avoid copies of the variant (if that is the concern), as the only thing which is needed is a copy of the accessor VI (shown above) wherever a variable is needed. There is no need to bother with a polymorphic VI as the output variant is of the requested type and will easily convert to the right type of wire with the drop of Variant to Data primitive, as long as the resulting wire is connected to a terminal. If not (for instance it is connected to a numeric primitive), then yes a polymorphic wrapper VI might be neat (but still a lot of work). When adding a new attribute, simply modify the Variable typedef and add a case. No VI should break. The only drawback of this approach is that that VI has to be non-reentrant and therefore, wherever it is used, this will interfere with parallelism. This can be to some extent avoided with DVR read action, which might be the reason the OP chose that approach. My 2 cts.

My apologies, I must have had a brain fart when I looked into that (I suspect isolating the vim from the VI I was using it and not connecting a "no error" constant to the input)? Things work as they should upon checking again.

When passing a "no error" error cluster to the "To JSON Text.vim" VI of the JSONtext toolkit, the output string is empty. This is not the expected behavior. I would expect: status = false code = 0 source = Tested with v1.9.1.125 in LV 2021 SP1 on Windows

The VI hierarchy window is fairly useless. For large projects, it is painfully slow to update. The links between objects don't make the architecture of a project any clearer. It cannot be printed with high resolution as a PNG or PDF file. Etc. Ignoring these shortcomings, it appears to not behave as expected: when selecting View>>Always Show Labels, collapsed library boxes expand laterally as if to accommodate the library label, but no label is displayed. I am labeling this as a bug, but maybe it isn't. Similarly, a library is represented by said box with an icon inside. The icon seems to be picked up randomly from one of the VIs in the library. This is not helpful. There should be a way to set a "library" icon (not just a template as defined in the library "Properties" window. Tested in Windows LV 2021 SP1 64 bit

There is no typos and errors in your posts. Only pearls of wisdom and oracles of truth that we mortals can't understand yet...

At this point, I have removed the single occurrence where I had used the toolkit, as the license would have been problematic to make my code acceptable as reusable.

That would great if someone from Averna could clarify that license. I can of course replace it by some alternative approach (especially since it behaves pretty badly when moving the parent window around, flickering like a bad neon sign :-).

I am confused about the license type of the Balloon Tip addon from Averna. The license text that shows up in VIPM does not mention any type, but somewhere says that: "1. GRANT OF LICENSE. Subject to the provisions of this Agreement, Averna grants Licensee a limited, personal, nonexclusive, nontransferable, non-assignable license to use the free Averna BALLOON Software (the “Software”) for your internal personal or business use (non-commercial) in accordance with the terms herein. ... 5. RESTRICTIONS. You may not sub-license, assign, rent, lease, transfer or otherwise distribute the Software. You may not reverse engineer, port, decompile, translate, alter, modify, disassemble the Software or merge the Software into any other software or otherwise attempt to discover the source code. You may not use the Software on another hardware platform. Averna reserves the right to make changes to its products or services without notice or obligation to notify any person of such changes." I was trying to find some wording to the effect that you can use the toolkit provided you include the license file, but the part I emphasized above seems to say you can use it for "internal" (to your business) use. First, I don't quite see how even for an internal use you can use the software without "merging" it into your own (in the sense that the code will need to be integrated to the rest to be actually used). And second, what is the purpose of a piece of code that you cannot share with others than those in your "business"? I am suspecting that the license file has simply been badly written. Any hint of what to do (save for avoiding the toolkit at all cost)?

Open the search function (Ctrl+F) and browse for the "NaN" constant. A dialog pops up telling you this palette item is not supported by the Find Dialog... You can search for the "NaN" string and it will find all the NaN constants (plus all the occurrences of the "NaN" string). You can search for all other constants (pi, machine epsilon, +/-Inf, etc.), but not for the NaN constant, which is just a numeric constant with NaN typed in it. You can search for ALL numeric constants, but not for a specific one, say "1". Of course, you can search for all "1" strings in your code, and the constant 1 will show up among the search results, but it will be hidden in a long list of irrelevant results. And try to search for a constant with units... You can't. What would be nice is to look for a constant irrespective of its unit, as for instance 60 s = 1 min. Did I encode that time constant as 60 s or 1 min? I need to search for 60 AND 1 to find out.

The idea is not so much to modify anything to the lvlibs, but merely to copy the original VIs instead of the version LabVIEW generates when releasing the source distribution. It doesn't make any sense to me, but the fact of the matter is that it works. I just used the result of the release (which files are saved where) to figure out which original ones I need and where I need to copy them (overwriting the released ones in the process).

Actually, you might need the code if you don't have the IDE installed. I don't think the runtime alone would be able to generate compiled code from the mere diagrams...

It might have nothing to do with the topic at hand, but I was recently struggling with the oddities of Source Distribution and libraries, and found out that a bizarre trick fixed my problem: Maybe you want to try that out. Just for my enlightenment: why do you want to embed the code in your VIs?

I tried the solution I sketched out at the end of last post and it appears to work like a charm, however moronic it may sound to have to do that to have a usable source distribution. The post-build VI I am using is shown below for illustration. The strange tidbit about llb's (bottom inside-most case structure) is something that I have added since the first version of that post as it turns out that LabVIEW doesn't deal properly with llbs when creating a source distribution. When finding a VI inside a llb (say myLBLLB.llb in the original code), it will save that VI in a subfolder called myLBLLB.llb in the distributed source. That will then result in some compilation error that will prevent the release of the distributed source. The above post-build VI nukes this folder and replaces it by the actual llb (and therefore keeps VIs in that llb that may not necessarily be needed).