Jump to content

Search the Community

Showing results for tags 'things about labview that suck'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • 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

Categories

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

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Personal Website


Company Website


Twitter Name


LinkedIn Profile


Facebook Page


Location


Interests

Found 2 results

  1. Something I did not appreciate till today: If I have an LVLIB library in which I use one of its VIs, then any LVCLASS class referred to by ANY of the LVLIB’s members will be loaded into memory (along with all their dependancies). In addition, the fact that all library members show up under “dependanciesâ€, even if only a few are actual used, makes it difficult to get useful information about real dependancies. So, should I ditch the use of LVLIBs altogether as a hopelessly-flawed tool? — James Added later: Must be getting old, as I forgot that I already knew this. But the question remains of what to do about it.
  2. I cannot figure this out. I made some changes to the private data of a class that caused the various unbundle nodes to get mislinked when they tried to auto-select the right new elements, leaving several broken methods. No problem, I thought, I will revert to the previous clean copy in Source-code control (using TortoiseHg). However, whenever I reopen the class, the unbundle nodes are still mislinked and VIs are broken! I reverted the entire codebase to a week ago to be sure I had a good copy, and I rebooted the computer — still broken! All my methods, even the unbroken ones say they need to resave because “Type Definition modifiedâ€. My question is: what is modifying my “Type Definitionâ€? It can’t be any of my source code, so what can it be? Where is the change located on disk?
×
×
  • Create New...

Important Information

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