Jump to content

Search the Community

Showing results for tags 'active review'.

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

  1. This OpenG Review is active. There are a few outstanding issues with the Variant Configuration as well as some feature requests so I thought it would be a good idea to start a summary thread to track them as well as to review all of these at the same time (in case of interactions etc...). Note: What will be implemented and when is not the point of this thread - that will be decided at a later date by the OpenG Team. If you know of an issue (link to an existing thread LAVA or OpenG), want to report something or have a new idea please post in this thread. For anything new, please create (or I will create a) new thread so that it can be discussed in detail. Please do not discuss these items in this thread - use that item's own thread. The point of this thread is to bookmark and manage these items for review I will keep this original post as up to date as possible An item with an ID link is a link to an OpenG Tracker Any item with a description link is a link to an existing thread (LAVA or OpenG) I am pretty excited to see work done on this OpenG Library as this is my favourite OpenG API. Kind Regards Jonathon Green OpenG Manager Current Items for Review: ID: 3411108 - Recursive OpenG VIs should use native recursion (if performance benefit) ID: 3409853 - Reentrancy bug in Write Key (Variant) VI? ID: 1501747 - Unnamed cluster elements cause problems ID: 1156973 - Fixed size arrays & Read/Write Panel to INI ID: 3004519 - Use custom decimal sign for floats ID: 849694 - Units in INI-files? ID: 848288 - Missing Key output ID: 3004517 - Writing to Panel deprecated issues (LabVIEW 2009) Bug: Read Key(Variant)__ogtk.vi: VI looses variant name Throw error on duplicate data Cannot load an array of classes using variantconfig
  2. This OpenG Review is now closed. This review relates to this thread here regarding support for the Timestamp datatype in the Format to String VI (among others). With the release of OpenG LabVIEW Data Library 4.1.0.16 it is now possible to parse Waveform and Refnum datatypes correctly (read about the original ideas here) e.g: Waveform (Timestamp) Refnum (VI Server) Therefore this review deals with how to modify the Format to String VI and subsequently its complementary VI Scan Variant From String to support Timestamps. Currently the Format To String VI is in the process of being modified to support: U64 and I64 DAQ Refnums Waveforms (example only - to be discussed here in review) Ideally we would like the same functionality mirrored in Scan Variant From String where possible: However the issue is that is seems that a Timestamp which has been formatted to a string can only be scanned back using the format specifier %T and must have been formatted using the Format to String and not the Format Date/Time primitive. But the Format Data/Time primitive is a more readable string and might be preferred i.e. to format a Timestamp to a string with no intention of converting it back. Therefore the main question is: How would you prefer to see this integrated? What formats should be supported? Should multiple formats be supported so the user can choose which, acknowledging some will not be able to be converted back? To aid this discussion attached is a code stub (if it helps) to get you started if you want to post code. Kind Regards Jonathon Green OpenG Manager
  3. This OpenG Review is active. Community, This VI was in the Candidates folder for the String Package. It has been sitting in there for a while therefore, I have just gone ahead and posted as is (so the license will be migrated on confirmation from the author etc...). What are you thoughts on this VI? Would you like to see such a function in OpenG? Can you optimize the code? It may be better suited in e.g. Comparison Package? Should it be rejected? Kind regards Jonathon Green OpenG Developer Is a GUID.vi TEST - Is a GUID.vi Code is in LabVIEW 2009
×
×
  • Create New...

Important Information

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