Message : "LabVIEW no longer supports this function..."

Question

When you try to open a VI built in 7.1 using version 8. x and if it has a function like Open/Create/Replace file.vi  or Write Characters to File.vi , you get a message that says LabVIEW no longer supports that VI and instead use of another VI is recommended.
Assuming I ignore this warning ( maybe there are too many replacements to be made ) and go ahead and build the VI with LV8.0, will something unforeseen happen ? Because despite the warning of not supporting the function,  LV8.0 App. Builder still compiles and builds the EXE using those VIs. I do know that LabVIEW is quite forgiving and tolerates inefficient code but I don't want to compromise efficiency if I can avoid it..
There are many instances when you need to modify code built with previous versions and it may not be viable to spend time to replace functions just to make them compatible with the new version.
Can someone enlighten on this ?
Thanks
Raghunathan
Raghunathan
LV2012 to Automate Hydraulic Test rigs.

Answer 1

The thing that you need to do is save those lists of warnings and go through them to see the comments matter. Some of the unsupported functions could be because the function they performed is no longer needed due to other changes in the language. For example, in V1 you had special formatting VIs to prepare data for plotting. Starting with V2 you could just wire data to the graphs and the display would morph themselves to match the datatype wired to them.
But back to you main point, it used to be that the changes that happened between one version and the next were of the sort that the conversion code could fix on the fly during the conversion process. There were things live terminals were moved around or the datatype of a function was changed. When you saved your code in the new version LV would simply reestablish the connection to the new terminals or insert a type conversion routine so the existing code would continue working. And let me be clear, LV still does that in most cases.
The problem is that NI has started making changes to the way the language works that are not possible to fix automatically. For example, the decision of whether or not to display scrollbars on a subpanel used to be a property of the subpanel - now its a property of the window being inserted into the subpanel. Now you could make the argument that logically this is the way it should have been all along (and I'd agree with you), but the fact remains that this isn't something that LV can fix on the fly because there's no way it can know at compile-time what VIs you going to be inserting into the subpanel. In the end, NI is left to make the decision whether to fix something that was implemented incorrectly the first time or leave it alone for "compatibility reasons".
Of course this opens up the question of how much input from the user community NI gets before making changes - which is clearly not enough considering all the uproar over the interface changes with V8.x. But it also gives me some hope that someday they may drop stacked sequence structures from LV - something that has been there since day 1 and has never really belonged in the language.
Mike...
Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion
"... after all, He's not a tame lion..."
Be thinking ahead and mark your dance card for NI Week 2015 now: TS 6139 - Object Oriented First Steps