X___

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.

I have a large project with many libraries which I am trying to release as a Source Distribution. I am regularly releasing standalone executables of that project without a hitch. However, the source distribution, once I open the top level VI in a copy of the project I place in the source distribution folder, after updating all paths to the new destination, ends up with many broken VIs. Examining the source of the problem, it appears that it is due to many (if not all) VIMs in my project being replaced by VIs with made-up names (random series of characters.vi), and the Assert Type VIMs in those VIs being themselves replaced by similarly randomly named VIs, and broken. I recall having read threads about some sort of incompatibility between VIMs and libraries, but since I did not have any problems with them during development (or application release), I am kind of at a loss as to what to do next... Is there some literature I can read on the dos and don'ts of Source Distribution release and VIMs + libraries? LabVIEW 2021 SP1 64 bits on Windows 10.

Thanks for the clarification.

Can you tell more? The site is pretty terse. Examples of topics discussed in past editions would be useful.

It takes a thief to catch a thief.

Feed an array comprised of non trivial equal numbers (e.g. a 1,000 values of 1.2345) to the Std Deviation and Variance.vi of the Mathematics>>Probability & Statistics palette and look at the standard deviation output using a display format such as that shown below: You will be surprised to see that the standard deviation is non zero and within the range of the precision for the type (~1E-15). While this might not be an issue in most use cases, it is still not an optimal result, and suggests that the calculation done in the called DLL is not optimal (it probably uses the standard formula, but because of round-off errors, the outcome is non-zero). I am posting this in the "bug" category, although it is not strictly speaking one, just to warn unsuspecting users (like me), that dealing with floating point numbers comes with its load of gotchas. Here is a snippet to experiment with the phenomenon: Again the display format of the standard deviation indicator needs to be chosen wisely to reveal the round off error.

I did that too but it broke a VI connection in one of the analysis VIs...

NI Package Manager is advertising a LabVIEW 2021 SP1 f6 version that I would like to learn about before installing it, but I am unable to find anything online. Does anyone have a better search engine (or insider trick on how to get the Package Manager to be helpful)?

Try decimate array?

This actually doesn't work as a general solution (one exception is enough to invalidate the rule, and I just experienced it). However, as stated before, I believe that as long as they don't break the code, LabVIEW's compiler hallucinations can be ignored.

LabVIEW's motto: Move slowly and break things!

Another example of tricks with units. The above formula works fine. If I want to check the value of the Boltzmann constant by adding an indicator where indicated: Things look fine but they are not: tested in LV 2021 SP1 64 bit

I date back from the pica.army.mil email list but never used Usenet. I am so not anonymous that I had a bunch of members of that mailing list drop by in one of my old labs say hi and gift me with a NI screw driver (this was back in the day where NI was gifting their users with goodies and trying to cultivate their relations with universities, just to give an idea of how far back I am talking about). I was already pestering about LabVIEW shortcomings (to my defense, that was pre-undo). Nothing changes...

Noted.

I am not sure I get it. What is that "post-processing VI" you are talking about?

Can this been downgraded to 2021 or earlier?

It starts looking like somewhere else on the internet (https://developer.ibm.com/languages/cobol/😞

So it is the new way to not release any info whatsoever ("NI did not create this content for this release") on new releases? I did not see any beta forum either during that all time. This is important to me, as I need to find funding for migrating my code base to a new environment, and any official evidence that NI/Emerson has dropped the ball to a new low (if I can forge this hybrid expression for the occasion) is useful.

Check this thread though: I wasn't able to take advantage of any multicore speed up and as for many NI toolkits, documentation is aspirational.

I think it is actually more trivial: the behavior I was observing is indeed related to an ancillary window opening, but that was triggered by a user-selected menu item. If I programmatically open the window, the "Mouse Leave" event doesn't appear to be fired (as expected). In fact, going to the menu bar triggers a "Mouse Leave" event. Why not. However, for some reason, the "Mouse Enter" event is not fired if the selected menu item is actually inside the window (which is almost always the case). This is what got me confused (or rather my code). So I guess my question is thus: why is the Mouse Enter event not fired when the user releases the mouse button after having selected a menu item?

It's a very dead thread but it's the one I found when trying to figure out why a "VI Mouse Leave" event is fired when I open another VI programmatically even when not activating that VI. Since that has been suggested as being the source of the OP's problem (but then NI suggested it was a bug with the Abort method), I am wondering whether this is expected behavior or a bug (which would then still be alive in 2021 SP1 which I am currently using). If this is a feature, I am trying to understand the logic: a VI is opened and set to not be inactive, yet the Mouse is supposed to have magically moved to that VI's front panel, even if it is nowhere close to it?

As mentioned earlier, I have happily left the Apple eco-system at the end of 2020, but one of my users is a die-hard macOS fan and has decided to try running my 2021 SP1 64 bit executable on a M1 MBP running Parallels Desktop 18 (Windows 11 VM). The code looks like it works fine, until some weird differences with the native Windows app start popping up. For instance, a variable loaded from an XML file is internally converted to a value that is ever so slightly different than the one it adopts on a PC (as seen in a printout of the value converted to ASCII). In an another instance, the comparison of two floating point values, loaded from two different files, which "passes" a preset criterion on PCs, fails the test on the VM... I don't see that there is any way to easily predict this type of problems and foolproof the code against them, so I believe I will just not recommend trying to use Parallels Desktop VMs to use my code on a Mac.