ShaunR

You should contact the developer. It may use features not available in earlier versions and it is a source control nightmare maintaining subtly difference versions.

Retrieve Token String.vi

I'll caveat this with this is only my opinion as a European. Market forces may be completely different to my perception in the US. When I first started, LabVIEW was basically a loss-leader to sell hardware. The sales people would give it away free (or heavily discounted) if you bought the hardware. It proliferated and people like myself learnt and expanded our capabilities. Over time it launched a small consultancy industry specialising in LabVIEW. There were a few major successes such as JKI and some partnerships along with single developer consultants. The test and measurement industry had few rivals to LabVIEW's capabilities. Fast forward to today and I think the emphasis is now firmly on large organisations with enormous hardware requirements-in particular governmental organisations. CERN is an obvious one in Europe (CERN being intergovernmental) but I believe there are many in the US. The Test and Measurement was, for the most part, lost to Python and although there are one or two consultants still operating in my neck of the woods, that part of the industry is basically gone here. So. In my view there is still an appreciable number of opportunities working for large companies' in the US and Europe but if you are looking to be a self employed contractor (in Europe) then you would be better off with something else.

For C/C++ I always use MingW (sometimes in MSYS2, sometimes in Codeblocks) but I prefer Pascal (Free Pascal compiler). Is this something you encounter mainly in MSVC?

The main difference is who cleans up the stack after a function. But again, I have avoided name mangling/decoration because it makes it difficult to figure out what to call. I guess being a mid-wit has saved me again

Ah right. It would be another one of those things I never came across. My API's rarely use functions outside of the binary it is wrapping (exception being ECL which uses some windows functions for things like the certificate store). I tend to use cross platform binaries so windows specific library calls are rare and unlikely to be cdecl. I disagree it is ill advised protection. One of the reasons I chose LabVIEW to start programming in was because it was bullet proof. I think we have had a conversation before that I never encountered crashes in the early days and it would have been because of ant foot-shooting boots like this.

I would probably never have been able to resolve an issue like that. What kind of monster removes anti foot-shooting boots? It's highly likely it was just me misconfiguring some CLFN's. It's obviously been fixed in later versions. I still use the API so would have known if there was an issue with 5.0.0. I think version 1.3 was about 2010 so that version is over 16 years old - an amazing testament to LabVIEW's compatibility really.

Not necessarily but possibly. Pointer to data instead of value or vice versa, enum sizes, pointer de-references of strings etc. Library calls are trixy.

Indeed. That is usually the result of misconfigured CLFN's.

It is probably one or more misconfigured CLFN's somewhere that was fixed in later versions. It was worth a try though.

If you didn't use the encryption then you could use the SQLite binaries from SQLite.org to keep you running while you transition. I can't remember off-hand if it was supported in 1.3.1 but adding AES=NONE to the project conditional symbols enables the use of vanilla SQLite binaries (i.e. comments out encryption function calls). That said, I expect the issue with LV2025 is probably to do with calling parameters rather than the binary itself because V5.0.0. seems to work fine with LV 2025 & 2026.

If you have a commercial waiver then there is limited residual support but apart from that, you should be looking to transition to an alternative product.

The SQLite API for LabVIEW was retired 6 years ago (at version 5.0.0).

There is definitely space in the market at this level. The success for LabVIEW is almost entirely dependent on the drivers and ease of application deployment. This is where, historically, NI have the upper hand as they have an integrated solution. Other platforms can get complicated