Jump to content

Search the Community

Showing results for tags 'to break or not to break'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Software & Hardware Discussions
    • LabVIEW Community Edition
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • GCentral
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
    • OpenG
  • Community
    • LAVA Lounge
    • LabVIEW Feedback for NI
    • LabVIEW Ecosystem
  • LAVA Site Related
    • Site Feedback & Support
    • Wiki Help


  • *Uncertified*
  • LabVIEW Tools Network Certified
    • VI Scripting
    • JKI Right-Click Framework Plugins
    • Quick Drop Plugins
    • XNodes
  • General
  • User Interface
    • X-Controls
    • Custom Probes
  • Database & File IO
  • Machine Vision & Imaging
  • Remote Control, Monitoring and the Internet
  • Hardware

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Personal Website

Company Website

Twitter Name

LinkedIn Profile

Facebook Page



Found 1 result

  1. 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.
  • Create New...

Important Information

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