Read Spread sheet string in Latest Version2015 has updated with New VI

[PalanivelThiruvenkadam]

Hi All

Not sure i am the one who is providing this suggestion

Hope everyone is aware that Read Write Spread Sheet string has been updated with different names, i hope that it serves the purpose of earlier Functions too.

When we are trying to open a code 2015 which is developed in earlier versions Read and write spread shett string shows Red cross mark.

Though it works without any issues it will be good if it automatically gets updated with New VI's. if its left as it is just not to create a conversion from 2015 to 2014 the same technique can be followed.

.

[RavensFan]

I don't think this idea will go anywhere.

There is a reason that NI created a new VI name and icon for the new and improved version, but left the old version in LabVIEW for now with the red X.  Usually it is because there may be some subtle changes in the VI that make break old VI's if the migration process that NI uses to update VI file versions just swapped them out without warning the programmer and giving them a chance to investigate and adjust.  You don't see it very often, but there are some other VI's that exist that relate back to functionality that changed after LV 4.0,  or others after LV 7.0.

Rather than breaking old code by just automatically swapping out an old VI for the new and possibly breaking your VI, NI makes an update that shows you are using a "deprecated" VI.  Still functional, but on the path to osolescence.

They put a lot of thought into how to handle these migrations and only do it this way when they have a very good reason.  It is better to have the programmer make a conscious decision and take action to update their VI rather than NI doing automatically and potentially unknowingly break your program.

[X.]

Moreover, as reported elsewhere, the "replacement" of the old by the new VIs results in an insidiously erroneous wiring (that is, unnoticeable until you get bitten by the problem).

[RavensFan]

Thanks X.

That might very well be the reason.  Perhaps if that connector change didnt' happen, the new could have replaced the old automatically without problem.  (I'm not sure if there are any other changes that could have been an issue.)  So a manual replacement is a problem that has to be fixed like in the link X posted.  But an automatic replacement becomes an even bigger problem and needs to be prevented against.

[PalanivelThiruvenkadam]

Thanks for the update.I thought like as both does the same function there won't be a issue even if it's updated automatically.I failed to forsee the problems that will cause if it's done

[X.]

I think NI overlooked the problem themselves (hence the CAR).

[AristosQueue (NI)]

We deliberately did not automate the substitution because of the change in runtime behavior between the old and the new. The conpane change was a secondary concern. We try to make sure that on upgrade your VIs continue to function as they did before unless there's a bug we are fixing. We are not always successful in that attempt, but we do try, and in this case, we succeeded by NOT automating the replacement. If your code is working with the old VIs, we did not want to break something by replacing them.

[Darren]

Declined for the reasons listed by AQ: "We deliberately did not automate the substitution because of the change in runtime behavior between the old and the new. The conpane change was a secondary concern. We try to make sure that on upgrade your VIs continue to function as they did before unless there's a bug we are fixing. We are not always successful in that attempt, but we do try, and in this case, we succeeded by NOT automating the replacement. If your code is working with the old VIs, we did not want to break something by replacing them."