X___

Let's clarify: if you develop in LV 2020 and use the released standalone with LV/Vision 2020 RTE, I am assuming there is indeed no problem (I haven't tried) If you develop in LV 2019 and use the released standalone with LV/Vision 2019 RTE, things work fine (I have tried, box checked or unchecked). It is only when you release in LV 2019 with checkbox checked AND use the released standalone with LV/Vision 2020 RTE that things go South (my experience of that is indirect: a user reported a problem that sounds related, but I can't verify that it was that specific problem, as it was subsequently solved by using LV 2019 RTE - I think. However there have been two other reports above that seem to confirm this pattern. It would be nice to have NI look into it in order to move from the anecdote level to the bug tracking one).

I am not sure I understand the reasoning. The DMC image display control is just a cosmetic modification of the original control. It doesn't change anything to the underlying coding. It seems to become a consensus that checking that box sounded like a good idea, but turned out to be a very bad one in some cases. I have stopped checking it when releasing a standalone app, as I don't have the bandwidth for testing all corner cases. Again, as long as nobody reports the issue with NI, nothing is going to be done about it. I won't because of the above sentence, but someone making his or her living from products developed with these tools might want to send a wake up message to NI. You can't engineer ambitiously if you dread every single checkbox in the application builder.

Sorry, I didn't realize that I was trying to "steal" diagrams. Thanks for clarifying.

Now that makes perfect sense.

So NI knows that their password protection is a joke, but they are still using it. No comment.

Well, I presented a clear business case against locked diagrams: they prevent the Analyzer (a NI product) from working correctly. Following your logic, I wonder why nobody has thought of preventing people from using pointers in C because they could crash their software? Providing detailed documentation is not a NI priority, we know that. Fine. Their market share is plummeting in the software development arena, especially in academia. Are the two correlated? Maybe. I am certainly not at war with NI, and my leaving NI forums a few years ago is due to the fact that I felt that my inputs had zero value for me (no practical influence on NI's development). I am stating my opinion, and you are free to dislike it. As for my own code, I have released some of the source code of my "lighter" programs. Releasing and documenting 1,000s of VIs that nobody will ever look at is not something that I can afford as a single developer. But truly, I wished this was all made easy and natural by NI, and there was a striving community of LV developers in academia that could vet and pinpoint bugs in some of my code. I am lamenting the fact that 25+ years of investment in this development environment are going down the drain and will leave no legacy because what was a truly brilliant concept got killed by corporate miscalculation ($2.5K annual single license originally - or maybe more -, no mechanism for forward compatibility from version to version). Time for a python fork with graphical IDE?

My ignorance amazes me, sometimes most of the time...

Then we agree that it would be best to release the source code, since this would point directly to another culprit. And BTW, as we discussed in another thread, I believe that there are still some "native" (as in NI brewed) implementations of some of the analysis routines (with their associated corner case bugs). This being said, regarding password protected VIs, I just ran into a LV Analyzer error due to one of the VIs calling one of the User Tags VIs (which are protected because they probably use some super-secret call which are not supposed to be left in the hands of peons). Which is pretty ironic, considering that both are written by the same NI developer...

Easy and we'll know what we are using. It's an academia thing, I guess, where a mistake haunts you for the remainder of your career, unlike in industry. You know, miles vs kilometers... I suppose we need to "follow the rules about filling out the form to document our concerns" too!

Let's start with unlocking all VIs and documenting Math DLLs...

I don't know about the future, but seeing how dynamic the first public beta is, the present is not particularly bright 🙂

Following this post, I installed 2019 SP1 in the hope that what I was experiencing was what was described as Bug number 217468 here: Right-Click Menu Commands Fail Intermittently Some right-click commands fail intermittently. For example, the VI Analyzer command Create » #via_ignore bookmark creates the bookmark but then erroneously deletes it. Workaround: Fixed in the LabVIEW 2019 SP1 f4 Patch. I don't use VI Analyzer (that much) so this is not what I have been experiencing (see post above), but 2019 SP1 f4 certainly did not fix it. I guess this is a bug indeed, but I am surprised that none of the power users around here have experienced it. Maybe they are all heavy Quick Drop users.

OK, I'll blame MS...again: https://forums.ni.com/t5/LabVIEW/Create-Folder-Buggy-Dialog/m-p/1504232

I am trying to understand an odd behavior of the File Dialog Express VI which I tend to use in most of my UIs. The snippet below provides an illustration of what I am discussing next: Generally, I will pick an existing file path for start path and either a default name, or one that makes sense in the context for name or relative path. Here an hdf5 file extension is added to/replaced in that template (but this is irrelevant) and the resulting (generally) non-existing file path is fed to the File Dialog Express VI (configured to accept single file path, new or existing files) as a two part input: - start path defined in the Help as: Path of the directory (my emphasis) whose contents LabVIEW initially displays in the dialog box. If start path is valid, but does not refer to an existing directory, LabVIEW strips names from the end of the path until the path is a valid directory path or an empty path. If start path is invalid or unwired, the last directory viewed in a file dialog box initially appears in the dialog box. - default name defined in the Help as: Name you want to appear as the initial file or directory name (my emphasis) in the dialog box. The default is an empty string. The strange behavior I am observing is that: (i) if the user accepts the proposed path, it is passed along right away (that is not the strange part), but (ii) if she/he/they move up one folder and press OK, the dialog will pop-up again and essentially refuse the proposed path (this is the strange part). If the user presses OK, the path is of course accepted as we are back in case (i). (iii) The only way to achieve what step (ii) is supposed to do is to move up TWO folders, then press OK once (which brings the dialog back up) and then once again. Any idea why this would make any sense or whether this qualifies as a bug? PS: obviously the above are just preliminary steps to creating/opening a file and saving data in it, but this is irrelevant to the discussion.

Thanks for the heads up. Still using f3. I am surprised that I haven't been nagged by NIPM yet... Is that patch even documented anywhere?