Find deprecated node

[TiTou]

Here's wizard utility based on StephenB's template VI and on the VI that I posted here.

The purpose of this utility is to scan a project (or a VI) and it's dependencies to find if any deprecated property nodes or invoke nodes are used.

Deprecated property nodes appear in red, and are not garanted to work correctly or to work at all.

Example :

After launching the utility, select the project you want to scan and then hit the buttons to scan for deprecated property nodes or deprecated invoke nodes.

The VIs in your project that use deprecated nodes will have their block diagram opened and the deprecated nodes will be highlighted.

user.lib, instr.lib and vi.lib are ignored by this utility.

Recommendation :

In order to be scanned the VIs will be loaded in memory if they aren't already, so the utility will run significantly faster if it is launched when the main VI (and dynamically launched VI) is opened.

To install, simply use VIPM.

Evolution :

1.2.0.4 : initial version

1.3.2.7 : can now process a VI and it's subVIs or a project and it's dependencies.

[Bob_Y.]

This looks like something that should also be built into a VI Analysis Toolkit test. Oh, wait, it is already there.

Bob Young

[TiTou]

I'm not sure but I think it is in the VI Analyzer toolkit and if it's not it should!

Ultimately my intent is to give the ability to replace (or not) with another property/method and when possible to even suggest a replacement property/method ; for instance I know that the "OS Window" property has been replaced with the "Native window" property.

Of course in some cases replacing with the up to date property/method would break the VI because the inputs and outputs are different but breaking a VI that needs the developer's attention is ok, no?

[rolfk]

You should watch out here. I think it's indeed ok if the code breaks in such cases but your particular example about OS Window is an example that wouldn't break the compilation but will go likely bad when run on 64 Bit LabVIEW.

The reason this property was changed is supposedly because Windows handles are all really pointer sized. OS Window is however a 32 Bit integer and simply changing that to a pointer sized value might cause undedected problems when moving to 64 Bit Windows. So they introduced a new property that supports the necessary 64 Bit value, so that when moving a LabVIEW VI to 64 Bit LabVIEW everything stays fine.

It could work for quite some time even in 64 Bit LabVIEW since the problem gets only apparent when the value exceeds the range for a 32 Bit integer, which is not likely to happen on nowadays systems, but over a few years when standard PCs likely will have 64GB or more memory this can easily turn into a problem.

Replacing OS Window with NativeWindow property automatically however will just hide the problem even more subtly. LabVIEW returns a 64 Bit number now, but the code working with this number still is likely working on 32 Bit values and LabVIEW simply introduces a coercion too. This will work fine on 32 Bit Windows and/or 32 Bit LabVIEW and might even work for quite some while on LabVIEW 64 Bit, but it will at some time break and having replaced the property node may make it even less likely to start searching there for the problem.

[TiTou]

Thanks Rolf for the warning and details, I was suspecting that the replacement of "OS Window" with "Native Window" was something to do with compatibility between 32/64bit OSes, however I didn't know about the details you mention.