X___

Interesting. I forgot that maintaining an active SSP was cheaper than paying for the software upfront (I am not dealing with that aspect). Now I wonder what "access to historical versions" means. Can we try to run LabVIEW 1.0 on a Macintosh VM? LabvVIEW 2.5 on a Windows 3.1 VM? That could be a lot of fun.

NI stock is doing fine. Some corporate brass sold a bunch of their shares (to the benefit of some family trusts...) either creating a dip in the stock or anticipating it, but that was transitory, and things are back to normal. The point is that LV was most likely never a driver of sales and as someone said before, they don't need it to sell their hardware anymore, thanks indeed to the free support of other development environments, which did not exist in the 90's. I am repeating myself, but as much as I enjoy graphical programming, I see no future for it in the academic field, where open sourcing and reproducibility (R, Jupyter or Mathematica notebooks being one way of ensuring it, preferably online), is (slowly) becoming the norm. Obviously, the situation is a bit different in industry. I honestly don't see what the big deal is with this announcement (which I pictured earlier as a price cut), as surely a couple thousand dollars per workstation per year can't create that much of a difference for a successful company, even a small one that would decide to wait and see before upgrading to the new yearly bug fix. Last year's official abandonment of any effort to revamp LV, was the nail in the coffin. This is just a confirmation that there is nothing more to expect from it.

Sounds reasonable. In this scheme, it seems that you can hold off on upgrades, as long as you pay your subscription. So, for most practical purposes it is a cleverly framed price cut...

I'd be curious to know what will happen to released applications (standalone) and toolkits.

As an update to my specific case, just in case this can be of use to someone facing the same issues, I finally managed to get access to support, after some surrealistic back and forth with the same guy at NI (part of the surreal nature of the experience is due to my decision to call repeatedly despite having faced failure after failure - I guess there is merit in repeating the failed attempt over and over again after all!). He finally mentioned a "product ID" number associated with our departmental account (even the name of which for some reason is not recorded properly by NI). No one thought about mentioning this number until that umpteenth call, even though it is listed as one of the options to verify the service program membership: The question now is whether anyone with that service ID can request support irrespective of them being officially associated with our service program membership. I wouldn't bet on Ni knowing the answer to that one...

Let me throw a wrench into that ambitiously engineered green picture. As an academic researcher, I have witnessed a progressive retreat of NI from campuses over the years. This will completely dry up their potential pool of users when students become engineers. Consider us the canaries in the coal mines. Recently, I was denied online support (couldn't fill a service request) because supposedly I was not associated with the Departmental license number I have been using for over 20 years. Trying to add my name to a putative authorized users list failed (NI seems incapable of figuring out how to do that), so I was invited to go through the IT person who is nominally in charge of renewing the license (which NI forgot to remind them to do during the pandemic, which added to the confusion). Imagine how convenient that would be... Before this, my last experience with NI support was rather negative (I discussed the symptoms I was experiencing - and still am - here: ). I provided all the logs I could, had a live demo session with no less than 2 support engineers, and they finally decided to give up after supposedly escalating the issue. Unsurprisingly, their last resort suggestion was to upgrade to the newest version (I cautiously stuck to 2019 SP1 to avoid the ripple effects of the pandemic and the NXG fiasco). So if this was due to a bug, the hope was that this undiagnosed bug had been fixed in the latest version...magically I suppose.

Tell us more about that time... Was that before the release of the first Windows version? I have the two demo disks for the 2.5.1 Windows version sitting on a shelf (never used by me, I just found them among stuff left by a retired employee).

I suggest LabdejaVIEW...

It does hang in LabVIEW 2019 SP1 f4 64 bit Windows 10. I am betting this one will never be fixed. This being said, how did you create that graph? If I pick a new one and try to manually enter the same upper and lower bound, it will usually just swap their order and not let me change the second one. If I try programmatically to set the max and min range of the scale, I get the following displayed values: 0.000125173 0.000113794 Playing with increment or precision doesn't help...

Clearly not trivially hackable.

I don't think I'll be around for LabVIEW 21xx.

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?

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