Jump to content

Search the Community

Showing results for tags 'composite'.

  • 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. Hi, I would like to play an idea out to you about having a composite class put itself back in its owning object by a DVR. Is that a good or a terrible idea? Background I need a class that represents some different LabVIEW files, and which can offer some operations on those files; LVFile.lvclass. LVFile.lvclass has some children (LV file types) and it owns a composite object LVFileRefs.lvclass: LVFileRefs LVFileRefs contains the following: - An enum stating the file type. - A reference to the LabVIEW file (class reference, library reference, project reference, or VI reference). - The path to the file on disk (if it is saved to disk). - Info if the refnum was created by the object or passed in from the outside (used by the Close method). I need LVFileRefs as a composite object (instead of that data living inside LVFile) since New starts by instantiating an LVFileRefs object before New can decide which child to instantiate: One of the responsibilities of LVFileRefs is to keep disk path and file reference synchronized. This means that you could start out with a VI in memory for instance, and create an LVFile object for that. This does not yet have a File Path. If you then save that VI, then LVFileRefs will update its internal File Path field from <Not-A-Path> to the proper path. If for whichever reason the original file refnum goes stale, LVFileRefs will also be able to open a new refnum from File Path if possible. All transparent to the user. So LVFileRefs maintains a firm grip of the file whether it being in memory only or on disk, and it can tell you which type it is (some types take more programming to tell apart than others, and type can change as well). All stuff that makes writing apps that handle many different file types simpler. No DVR approach Normally I wouldn't expose a naked refnum to the user, but one of the features of LVFile is actually to serve the proper refnum, so in this case I do. That is currently done with accessors on LVFile, and then an LVFileRef method: Since LVFileRefs can update its embedded refnum it is important to write the LVFileRefs object back into the owning LVFile object (or else Close for instance wouldn't close the correct refnum, and several other issues). DVR approach Having to write back the LVFileRefs object is error prone - the user could forget to do it, and having to do it in the first place is irritating. I'd rather you could omit the write back step: The idea is to have LVFile embed a DVR to itself inside its LVFileRefs object, with which LVFileRefs can write itself back into its owning LVFile object with whenever LVFileRefs has updated itself. There shouldn't be any racing possible, as LVFileRefs is actually the representation of the LV file, and DVR access is mutexed. Am I insane considering this? Cheers, Steen
  • Create New...

Important Information

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