X___

9 hours ago, ShaunR said:

Of course there is something they could do. I expect the use of the ANSI versions of the file operations is making them resistant. I've my own set of compane equivalent of the native file operations that do it just fine - it's the Path Control that is the problem.

I am trying to understand what you are staying but I am obtuse.

In the snippet above, if I connect a constant path whose length is longer than 260 characters (path length not file name, the file name of course needs to be <260 characters), I get an error 6 as @thols mentioned below (but that is not what I am doing, I am using the native file dialog, which results in the file name to be silently truncated).

If I try to save a file with the same extra-long path in Word, it works just fine, as it does in Notepad++, for example.

I do have LongPathsEnabled set to 1 on my Windows 10 Pro system:

I have read some mentions of this failing in Notepad++ for instance, but this turned out to be related to people having the wrong registry settings.

Anyway, I guess I have my question answered: LabVIEW 2021 manages some wire kinks better than before, but as far as file paths, it is still stuck in the past.

The KB says:

Disclaimer: LabVIEW does not support long path names on Windows. Although Windows includes support to enable LongPaths in the Registry Editor, each individual application must have this support included in the code.

I am reading this as "LabVIEW does not have this support included in the code". Maybe I am reading this wrong. I don't think so, see below.

As for being silent, try the following snippet:

When prompted for a path, just navigate down a deep folder hierarchy and enter a name long enough such that the sum "folder path" + "file name" is larger than 259 characters (1).

There is NO error. The file is saved with a truncated file name (so that the path remains smaller than 260 characters) (2).

Note 1: if you type a FILE NAME longer than 259 characters in the file dialog box, Windows will beep and prevent you from typing a longer name, so you would know that something is wrong.

Note 2: you can edit the file name in Windows Explorer (as long as the NAME remains below 260 characters), such that the file PATH length is LONGER than 260 characters, so yes, Windows does support path name than are longer than 260 characters.

Just curious whether anyone can check whether the 255 character file path limitation is still a thing in LV 2021:

https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z0000015AHaSAM&l=en-US

I just got bitten by it again in LV 2019 and it is a silent killer, as it will truncate the input file path to 255 characters without the slightest warning...

Most relaxing Q&A session of all... 15 minutes of background music. That was necessary to let the breadth and depth of the new features which were crammed within the first 30 min sink in.

I was actually quite impressed that NI finally was on the right track as to what an autowire tool is supposed to do. Not that I am planning to turn it on, but pleasantly surprised nonetheless.

The important link is this: https://www.ni.com/en-us/support/documentation/bugs/21/labview-2021-known-issues.html

1135156 is nasty...

1555422 is sort of amusing for that new functionality. But I guess that is what happens when the feature is not advertised in the public beta site (https://forums.ni.com/t5/LabVIEW-2021-Public-Beta/LabVIEW-2021-Beta-Now-Available/td-p/4144143) 

I believe the "Final Time issued" section is new?

1 hour ago, mcduff said:

Just reporting that I used the DMC image control, had the box checked, and did NOT have a black image display. (LabVIEW 2020SP1, 64bit, Win10)

No commentary on whether to check/uncheck box. Just suggesting a possible work around for folks who may want to check the box.

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

13 minutes ago, mcduff said:

However, if it is checked and you want to use an image control that won't change colors in the EXE version, the Image Control in the DMC controls package available on VIPM does not suffer from this problem.

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.

12 hours ago, Rolf Kalbermatter said:

Consider the diagram password equivalent to your door lock. Does it prevent a burglar to enter your home if he really absolutely has set his mind on doing so? Of course not!

Is it a clear indication to the normal law abiding citizen to not enter? You bet!

There is no simple way to protect a diagram that the compiler needs to be able to read in order to recompile the program (for a different version, platform or whatever) without having a fairly easy way to also  peek into it for the person truly wanting to. In fact there are many ways to circumvent that. You could patch the executable to skip the password check when trying to open a diagram or you can locate the password hash and reverse its algorithme to get back at the password. The only problem is that this is an MD5 hash. So it is not a simple reversible algorithme, but MD5 is not a secure hash anymore, since with enough CPU power you can find a string (it does not necessarily have to be the original password since multiple arbitrary sized character sequences will eventually map to one single hash code) that results in the specific hash. It may take a few days and will certainly contribute to the global warming 😀, but it can be absolutely done. Chances are that that CPU power may be more productive in terms of money when directed at mining of cryptocurrency, even with the current dive in value. Another approach is to simply replace the password hash in the file with the hash for the empty password (which means unprotected). It's not as simple as replacing 16 bytes of data in a file with a standard byte sequence, since that hash is also computed over some of the binary data of the VI file, but it's also not impossible.

Why they didn't make it more secure? The only way to do that would be to truly encrypt it but then you also need the password to be able to recompile the code. But then you can just as well remove the diagram when distributing the VIs, as that diagram has not real additional value anymore, except that you as password owner don't have to maintain two versions, one without diagram to give to your user, and one with it for your maintenance and further development. You would end up with the problem to have to distribute your VIs for every LabVIEW platform you want to support or hand out the password to your users in order for them to be able to compile it for a different platform or version. 

Basically to come back to our door lock: The security you are expecting would be pretty much similar to replacing all windows and doors in your house with a concrete wall and only leave one single door that is heavily steel enforced, with quadruple high security locks and self shoot installation in case of entering the wrong code more than 3 times. Very secure but absolutely not comfortable or practical and potentially lethal to your family members and friends.

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

2 hours ago, ShaunR said:

NI have said on many occasions that the VI diagram password system is not intended to protect IP - more of a disincentive to fiddle with diagrams (think of operators on a production line). NI's recommendation if you require stronger security is to remove the diagrams.

Now that makes perfect sense.

17 hours ago, ShaunR said:

Nah. You just haven't had a misspent youth like I have ;)

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

7 hours ago, Rolf Kalbermatter said:

As far as if NI could do that legally, yes they could. If they want to? Why should they? Are you releasing all your source code as Open Source?

And this is really meant seriously. Propose a meaningful business case why NI should release that source code if you were a manager at NI! And don't forget all the technical support questions of noobies trying to peek in that code, thinking they can fix something and then boom, everything goes haywire. There is no business case in the current NI software model for this. Unless NI decides to go .Net Core with their software, which I don't quite see happen yet.

Open Sourcing components that are not just nice to have libraries that you can more or less throw out in the wild according to the motto: Take it as is, improve it on your own or leave it! is only causing additional work and issues without solving anything.

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? 

3 hours ago, ShaunR said:

If it's something like Get User Tag.vi or Set User Tag.vi, I can guarantee there is nothing in there that would surprise you.

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

17 hours ago, Rolf Kalbermatter said:

If you really want to spend a lot of time and effort into this, the more promising way would be to simply start developing an Advanced Analysis Library replacement directly around the Intel Math Kernel Library.

That DLL interface you are talking about is mostly a historical burden carried over from when NI was still developing their own Advanced Analysis Library. Around 7.x days they decided that they could never compete with the girls and guys who knew probably best on this planet how to tickle a few percentage more of performance out of Intel CPUs, because they worked at the company who had developed those CPUs and so NI replaced the in-house developed AAL Math Library with the Intel Math Kernel Library. The DLL interface was left intact so there was little to be changed on the VIs that made up the AAL, but internally most functions in that DLL call more or less directly into the Intel MKL.

Spending lots of time for the documentation of that proxy wrapper DLL is not very useful. There are very few secrets in there that you couldn't learn by reading the official documentation for the Intel MKL.

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

46 minutes ago, Rolf Kalbermatter said:

Why?

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:

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:

- default name defined in the Help as:

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?

8 hours ago, hooovahh said:

Not sure if you are past this point or not, but be sure and take a VM snapshot at some point.  Having a fresh VM for a semi-standard environment like LabVIEW 2017 SP1 with DAQmx, Vision, RT (or whatever is common for your industry) is super useful.  Taking this another step you can have a snapshot for each project too.  Sharing this with team members can be a pain, so I generally just go through this process at the end, or near the end of a project, then archive the VM somewhere on the network for safe keeping.  

Could be useful, especially since I do not store the LV code in the VM but on the host machine, so essentially, there is only the development environment in it. It is backed up with the rest of my machine though.

I just spent a whole day setting up a VM and installing an older version of LV with the right toolkits and driver versions needed on my deployment machine because... versions and toolkits are incompatible and exclusive from one another. 10s of GB most of them useless for my purpose.

Awesome.

I am thrilled already 🙂

I followed @dadreamer's advice and now get verbose logs every time I get this. There are a few Insane object warnings I need to investigate in my main VI (some cluster constants), and some bizarre DSDisposeHandle errors pointing to that non-existing penguin path, a load of messages regarding references that couldn't be found in a cookie jar, some "this is dangerous" warnings, and tons of weird internal self-addressed warnings...

I may contact NI support at some point, but since it is not killing me, I have put that on the "to do" pile.

As a note, a quick performance test comparing dropping a constant or an error ring in a case and running this over and over doesn't seem show much of a difference in  terms of CPU (but benchmarking could probably done more carefully), so I may have just used up bandwidth for not much, as usual... 🙂

1 hour ago, Darren said:

During code reviews I always tell people to remove 'No Error' error rings and replace them with error cluster constants. As for non-0 Error Rings, they should always be in a case structure that only executes in the situation where you need that Error Ring value.

That's good advice, which could be added to the Help for the Error Ring, for instance...