05-01-2025 07:58 AM
With the CVI being in a de facto EOL state... thoughts on even considering it for new projects/designs? Usually a LabVIEW developer, some of my customers want textual code diffs for changes down the road and graphical diffs are, well...
So with CVI at least can be in the NI ecosystem still and enjoy a decent dev base of experience to draw off of, but with EOL and knowing how MS Windows behaves on future updates and releases, I'm hesitant to consider CVI at all if it's not going to be supported/made to work (e.g. on some kind of Windows 12, 13... and so on).
Only thing left is .NET, which is another level removed than I'd prefer from the NI ecosystem. At least with CVI the User Interface is a little more friendly in terms of not having to worry too much about updating it on the right thread etc (at least according to my noviced observations of CVI, could be wrong).
Solved! Go to Solution.
05-02-2025 07:57 AM
My department is starting to migrate our LabWindows-based test tools to Qt Creator. It uses C++ or Python instead of C, and we've had to work around some weird bugs, but overall it does the job.
05-05-2025 01:09 PM
Are you re-writing the code or try to re-compile the same code inside Qt Creator?
05-12-2025 04:18 AM - edited 05-12-2025 04:25 AM
@ebalci wrote:
Are you re-writing the code or try to re-compile the same code inside Qt Creator?
Unless you talk about normal function libraries, I do not believe that recompiling LabWindows/CVI code in another environment is going to be an easy or even feasible approach. Especially LabWindows/CVI user interface code is not going to cooperate well with other user interface frameworks including QT.
It can be made to work in a Visual C environment if you do use the according LabWindows/CVI libraries and don't plan on mixing and matching it with other Windows UI frameworks. But if you want to go WinUI or any of its predecessors such as DirectX, WPF or similar you will almost certainly have to rewrite the whole UI code at least.
And there were substantiated rumors that NI is going to do at least one more release of LabWindows/CVI. Probably not a good idea to start a new project with LabWindows/CVI nowadays but it at least lets you plan a more long term exit strategy.
05-12-2025 08:47 AM
Re-writing it using the Qt Creator GUI controls.
05-13-2025 02:19 AM
I've been using QtCreator on and off for a while but I'm very far from a good understanding of the whole Qt ecosystem (and I loathe C++). Can you have similar user interface controls: gauges, strip charts, etc ? Or do you have to make them from scratch using basic elements ?
05-16-2025 09:58 AM
Qt Creator offers many of the same GUI building blocks as LabWindows, including a Qt Graphs library that provides various types of charts and graphs. The signal/slot methodology takes some getting used to but it's not too hard for an experienced LabWindows user.
12-23-2025 07:16 AM
Sorry for the way too late reply, but those using Qt (in a commercial environment)... the costs seem pretty high for even small businesses? And its subscription based it looks like correct?
I suppose if your existing product/codebase was already proven and in CVI this would be a way to go if you're wanting to part ways with NI and CVI, but for new designs, it seems cost prohibitive for those projects/businesses on a budget. Hmmm...
12-28-2025 05:39 AM - edited 12-28-2025 05:41 AM
@taft220 wrote:
Sorry for the way too late reply, but those using Qt (in a commercial environment)... the costs seem pretty high for even small businesses? And its subscription based it looks like correct?
I suppose if your existing product/codebase was already proven and in CVI this would be a way to go if you're wanting to part ways with NI and CVI, but for new designs, it seems cost prohibitive for those projects/businesses on a budget. Hmmm...
Well if your main point for moving away from CVI would be cost and the subscription based license, then moving to QT is for sure just getting you in the same boat again. On the other hand, moving to something substantially cheaper also has its costs in other areas, aside from the entire porting effort. Most Microsoft based solutions are a continuously moving target that can change course with the mood of the day (or stock market or whatever hype is currently hot).
For existing systems that you don't have to maintain beyond occasional bugfixes and small changes it is for sure not a good idea to move away unless you have to provide to someone a 20 years continuous support warranty.
For new designs however I would say the signs on the wall have been clear for the past 5 years and the recent brief activity from NI seems NOT a company supported effort but more a single guy action or maybe some "contention mitigation".
01-08-2026 12:45 AM
I agree with other users here and I would not recommend CVI for new projects at all.
Migrating to another solution has a cost, both in term of money and effort.
Based on my experience, the only feasible solutions (in C or C++), for me are:
They have different good points and bad points.
None of them is ready out-of-the-box
As brainstorming, I wonder if AI can be used helping rewriting exidintg code from one framework (CVI) to another one (your choice).