X___

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).

Tested that, all paths are relative. As I mentioned, I moved my whole LabVIEW code to a different volume (by simply copying the whole development folder, preserving the folder hierarchy in which the different dependent libraries were located), and the project loads just fine. Since I am releasing the dependencies with the same folder hierarchy, I don't think this should cause problems to someone forking the repo. Having the dependencies in vi.lib would require messing up with the user's installation, which they may not want to do. I don't think I have any of those. I use a few polymorphic VIs, but none recursively. Overall it seems like I am better off writing my own source distribution release script, copying whichever file is needed, but that's sounds fairly tedious, as I would have to build a list of dependencies, etc. Or simply release a mock distribution to get that list of needed files, and then pick the original ones an copy them to my destination path?

This is too basic be of any interest to any of the gurus out there, so I am just typing this as a record of problems to be expected when releasing a source code in LabVIEW (in the way I had intended to do it). Recap: I have a development folder where there are a number of VIs that I do not care to release (in addition to other files). That folder is under revision control by git. I do not want to make that repo public, but I want to release the actual useful code in a clean repo. My approach: I select a Source Distribution in my project, in which I define which VI (+ libraries and other files) I want to save and where. There are a number of dependencies in other outside folders, which I export using the "preserve disk hierarchy" option to help with finding this VIs in the release. When running the build, I have no issue. I need to create a different lvproj file in my release (but this is a one of affair) so that it doesn't refer to VIs that have not been released. I essentially drag all the lvlib files I have exported into that project, and reorganize things within virtual folders for convenience. If I open the top level VI in that project, and run it, everything works like a charm. However, underneath the hood, everything is screwed up. Every single VI and library shows up as "in conflict". Opening up the Resolve conflict dialog doesn't help, as none of these conflicts appears resolvable (all "Select this version" buttons are grayed out). The crux of the problem is that there are two available paths for each VI, the new and the old one. Clearly LV knows which VI to load when running the top level VI (the new paths ones), but somehow, the project is "in conflict" anyway. lvlib files seem to refer to VIs by relative path, so they shouldn't be the issue. VIs seem to store absolute paths in their data, so I suspect this the cause of the problem. I have tried a number of workaround to fix the issue (releasing the distribution anew each time), to no avail: - selecting different options in the "Additional Exclusions" tab - uncheck "Preserve disk hierarchy" in the "Destination" tab - Move the source to the same volume as LabVIEW (so that there is no need to distinguish between files in "C:" such as Windows dlls and files in the other volume)

I have answered my own question by not checking off the "Disconnect unused inline subVIs" checkbox. However, I now have the issue that all the libraries in my Source Distribution now refer to the original paths of included VIs. This is strange as I have preserved the folder hierarchy when releasing the source, and I was under the impression that libraries, projects, etc. were relying on relative paths... There seems to be no way for me to resolve these conflicts, and even if there was, I don't think this is a practical way to handle this type of release. Does any one have any experience with this type of release (and actually tried to use the released source)? Note that the exported project, even though it is riddled with conflicts does let me run the top level VI just fine, as if all this complaining about conflicts was just for show.