Search the Community

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

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

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