Search the Community
Showing results for tags 'to break or not to break'.
Is it better for NI to provide backwards compatible (compat, legacy, oldvers, whatever you want to call them) VIs or to break the code when loading in a new version and requiring the user to understand the change and replace the broken code? I just spent a day cursing at the computer because of a single NI supplied VI called "Write to XML File". See dark-side post here if you care why... In my case, the NI function I called contained calls to subVIs labeled as unsupported. Would NI have cleaned this up if the practice of creating compatible VIs was not an option? Is this a failure of NI to use their own tools on their own libraries or a deficiency in the concept of compatible VIs? It seems to me that a compatible VI should be like deprecating a node in an SNMP tree. Its not supported anymore, but the interface info still needs to be available to allow for selecting a alternate method. My technique would be to provide a shell VI with all inputs required and a native function with required inputs empty to force the VI to a broken state. I would set the VI description to indicate the function is unsupported and provide suggested solutions and/or a reference to the release notes.