Jump to content

Search the Community

Showing results for tags 'strict typedef'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Software & Hardware Discussions
    • LabVIEW General
    • LabVIEW (By Category)
    • Hardware
  • Resources
    • LabVIEW Getting Started
    • OpenG
    • Code Repository (Certified)
    • LAVA Code on LabVIEW Tools Network
    • Code In-Development
  • 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 1 result

  1. Hi guys! I'd like to have my XNode to behave differently when the input is a (strict) typedef but also differently according to the typedef path (or name) if any. In a regular VI, this is easily done by extracting the path of the typedef: Terminal>Control>TypedefPath, but in Xnodes it's another story! So far I managed to get the regular type in the 'AdaptToInputs' ability (which is the common use of this ability!) and to see if it is a typedef or not by reading the properties of the control in the 'GenerateCode' ability. But in this last ability VI, an error occurs when I try to obtain the TypedefPath (Error 7). This error apparently occurs in Xnodes and especially Express VIs when "one of the internal paths is hard coded incorrectly" Is there a limitation due to the XNode or else? I guess that I could get around the problem by scripting the owning VI and retrieve the typedef of the control connected to the XNode directly but it would be quite cumbersome and ugly. Any thoughts on the subject?
×
×
  • Create New...

Important Information

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