Search the Community
Showing results for tags 'reference'.
I've been working a lot lately with by-reference architectures that still cooperate completely with LabVIEW's implementation of OOP and polymorphism. I've also recently taken an interest in trying to speed up development with secondary providers (similar to GOOP) to enable automatic creation of accessor VIs hidden behind the DVR, automatic creation of the private data type and constructor/destructor, etc. within the project window. I'm generally not a fan of the extra stuff that goop adds in to classes, I'd prefer to keep the source code looking as close to a normal class as possible. Tha
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 refe
I'm in the systems engineering group at NI. Over the course of the past year(s), we've received feedback (most recently here -- sorry, this link is in the ni.com/community CLA group so access may be restricted) that some members of the community would be interested in contributing to some of the projects we've already released, or potentially working with us to identify future projects that might benefit the community at large. We'd like to renew this conversation by opening up a discussion of what projects might interest the community. That discussion is posted here: https://decibel.ni.c