Jump to content

Recommended Posts

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.