Search the Community

I ran into an interesting issue with the Array of VData to VCluster when using XControl references as part of the VData. It looks like it puts it together correctly into a cluster, but when trying to type back to the XControl reference type it throws an error. You can convert it back to a normal control type, but when doing generic sets on controls in a cluster that method doesn't work very well. LV2011, Latest verison of the library. Screen shots here and code attached. I actually tried it with a couple different XControls and it didn't work. I wouldn't think that this behaviour is normal, but maybe there are some known restrictions when using XControl references? The references themselves seem a little weird because I did a source build on the project and it changed the type of controls in the "new" cluster constant when LabVIEW compiled it. They were just normal control references made from scratch in the source code and then in the build it changed them. They still said "Control" but when you clicked on them to view the ActiveX class they had Control and MRUFilePath selected. Weird. Anyway, I can probably manually cast these values, but the whole reason behind my method was I just had to add the control ref to a cluster in a class and input the refereces as a variant array and It would load them...no custom loading of the clusters. XControlRef.zip

This package will be available for download through VIPM in a few days and contains new VIs for working with LVOOP data created by drjdpowell. The API has been designed with optimization improvements available in 2012 in mind. The palette has been approved by asbo [NEW] 3484610 - New LVOOP Data Functions Kind regards Jonathon Green OpenG Manager

This OpenG Review is closed. See Summary Post here. Please start a new thread to discuss new changes to this VI. Read this post for start of review. I’d like to suggest these three VIs (or similar) as possible LVOOP-object additions to the OpenG Toolkit: “Get Class Name” is a modification of “Get Name of Class of Object” posted by AQ. Here it just returns the basic class name (which I use often in custom probes and the like). "Get Default Object” is inspired by this discussion and uses AQ’s zero-iteration loop method. This is a very simple VI, but using it instead of the raw code is much clearer to the reader. “Same or child class” just uses “Preserve Runtime Class” as a tester. Again, the advantage here is code readability (or it will be, as soon as someone comes up with a good icon for it). Thoughts? — James OpenG Suggestions.zip

This package will be available for download through VIPM in a few days and covers some bug fixes, performance updates, and new VIs. [FIX] 3386531 - Get Array Element Default Data does not support Timestamp [FIX] 3252254 - "Set Variant Name.vi" Kills Attributes [FIX] 3386530 - Create new Waveform and Refnum TD subtype VIs [FIX] 3386538 - Update Variant Constant to LabVIEW 2009 appearance [FIX] 3411109 - Recursive VIs should use native recursion (lvdata) [FIX] 3411324 - New VI: "Get Default Data from Variant" Waveform and Refnum Subtype Enums There are now new VIs and Enum Controls for determining the sub-type of Waveforms and Refnums datatypes. These VIs were designed by Jim Kring and solve the issue of parsing such datatypes as e.g. Timestamp (Waveform subtype) and VISA (Refnum Datatype). This will allow OpenG support such (sub) datatypes in e.g. Format To String.vi in the near future. Get Default Data from Variant This VI forms a thin wrapper around the Get Default Data from TD.vi complementing the Variant API nicely. You can New Variant Constant Image The Variant Constant image has been updated to be inline with the change made in a previous LabVIEW version both in the palette and on the block diagram.] There is no functional difference between the two constants. Here is a Test: Kind regards Jonathon Green OpenG Manager