Jump to content

Search the Community

Showing results for tags 'class'.

  • 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 9 results

  1. Hi all, I'd appreciate some advise or pointing in the right direction regarding building an EXE with class dependencies. I have a project built with actor framework and when I build it to exe, I get lots of dependencies which I think should be included in the EXE as seen below: On my Source files build properties page I currently have nothing under Always Included. I did try including all of the lvlibs and including them in the EXE but it didn't make a difference. In summary, I think the way my EXEs are building is not right. It is easy to see what VIs I'm using (although
  2. Goal: Find the best methods (or at least some good options) for message decoupling that are simple to implement and efficient to execute. Background: Messaging architectures in LabVIEW that use a class for each unique message type are strongly coupled to the recipient process (aka ‘Actor’). This is due to the need within the message execution code (a method of the message class) to access the private data of the recipient process or to call methods in the recipient process in order to do the work that the message intends. (See Actor Framework for an example of this). The problem aris
  3. If you have your class and you want to create a pull right menu on a property node for it, you can use the colon ( to separate property items for it. Just right click on the class » Properties » Item Settings » Localized name. Also, on a separate note and since I'm in the neighborhood, you could also take advantage of the "Documentation" tab in the Class properties to change the "Localized name" from the default (in my case, "NI_VSA.lvclass") to something shorter or more meaningful. .This makes it easier on the eye. Regards
  4. I am trying to export a class in LabVIEW 2013 to a .NET Assembly. According to this I can just select the members of the class that I want to export and it will generate a .NET class for them. http://zone.ni.com/reference/en-XX/help/371361H-01/lvhowto/building_a_net_assembly/ I am able to export the individual members of the class, but when I run the code in .NET it starts searching for mydllname.dll/myclassname.lvclass (the file of the class that the exported members belong to) and can't find it. My next step was to add the class to the the Always Included list, but it seems that
  5. Hi, Here comes a rather basic question but which I'm always struggling with since you can often argue both ways. Hopefully some of you have a few nuggets to share here... 1) A parent class should have no knowledge of any child class' concrete type, i.e. only data and methods that is inherently common to all decendents of that parent should be defined by it. 2) For dynamic dispatching to work the parent class must define virtual methods for dynamic dispatchees to work from. Those two rules often contradict each other. Methods vetted against 1) will often eliminate the possibility
  6. I've been bashing my head against the proverbial wall for a couple of days now trying to understand what was corrupt in my LV project hierarchy. On the face of it, all appeared to be fine, but I was getting some very unusual errors when executing my VIs. Errors that hadn't occurred before I rearranged stuff. In my project I have a number of classes, with various inheritances and other defined relationships, and I recently moved some things around to make it, well, better organised. I ensured I didn't destroy the relationships required to maintain access to class methods etc. Indeed, after the
  7. I have a hierarchy of classes. Call them Grandparent, Parent and Child. I have a dynamic dispatch VI in grandparent that child overrides. In the child implementation, I want to access data in the parent class control. The template in the grandparent has two inputs of type grandparent. The dynamic one and a static one. The dynamic one is used to dispatch to the correct child. (this is because grandparent has more than one parent sub class and these have more than one child subclasses) The static one is used to pass in a parent object so the child has access to its data between calls. (
  8. Hello LAVA, First time poster here, so I'll do my best with background. This situation also happens to be my first exploration of scripting LabVIEW Classes. I am starting with my simplest use case, and scaling as I see some success. I am simply trying to add an existing VI to a newly created class, and facing a strange message when opening the class that I have created. I have attached a snapshot of my code, BD.png The code runs without error, and creates a class in the specified directory with the correct name. What's strange is that when I open the newly created class to view its conten
  9. I have just been reading up on topics of OOP in general and although I've used things similar to Interfaces and Abstract classes in LabVIEW, I didn't realize I was doing it. Due to differences between different text based OOP languages and LVOOP I was just wondering if I could get some of you to speak to these two concepts, whether they both really pertain to LVOOP, and possibly provide some actual examples (not just vehicle, shape, cookie cutter examples, but something I'd actually use) of when you'd define an interface vs an abstract class? I'm basically just looking for general information
×
×
  • Create New...

Important Information

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