Shawn Walpole

I'll expand a little on what I'm doing since there were some requests. I use the MGI Read/Write Anything VIs to save data, but the Read/Write Anything VIs currently save LVClass data as flattened data in a Hex string. The LVClasses represent instruments that are used in tests. I've had lots of problems with changing the data inside the class and then having the unflatten fail because the saved data can't be mutated to the new class version. I know that LVClasses are supposed to handle this, so I don't know if I'm doing something strange or if there is another problem, but the first time it happened I just recreated all the instruments, and I assumed it was a fluke. It has since happened enough other times that I felt I needed to address the problem. In fact, I think I am just now realizing the problem; the file that contains the flattened class data is on a shared network drive. There are typically multiple computers reading the instruments, and its possible they run different versions of the software, so that if the new version reads the old LVClass flattened data and then saves it as a new version, then when the old version trys to read the data it will fail because it doesn't understand the new data. I should verify that this is what is happening. However, it is not practical to force every lab computer to update at the same time, so I'm still interested in saving the LVClass data in an ini format. I realize I would lose the mutation handling capabilities of LVClasses, but it is worth the trade if I can have old versions of the application able to mostly read the new versions of the LVClass data, which I think will work fine if the data is saved as text fields. Currently, I have added a "Write to INI" and a "Read from INI" dynamic dispatch VI to each LVClass in the instrument hierarchy. This gives me the behavior that I want, but it took several hours and I have to remember to update these methods every time I change the data of the LVClass. For all the other LVClasses I've written I haven't needed or wanted to arbitrarily save all the class data. This is the first use case where I've wanted this ability. My use case may be strange because all my LVClasses contain data that I want to be persistent and accessible from multiple versions of the built executable. It may be time for me to learn the LVClass mutation rules. I would welcome any comments about the wisdom or foolishness of wanting to save LVClasses into an ini file.

Hello François, Thank you for providing this API. I am using it to test a proof-of-concept of saving LVClass data in an ini file. The LVClass API has been very easy to use because of the excellent documentation, nice icons, and a well thought out palette layout. I did have 2 questions: 1) The "Close.vi" uses a merge error with the first error from a close reference. This will discard any error on input to the VI if there is an error from the close reference. Is this intentional? 2) There is a password protected VI "Get_Class_Hierarchy_From_disk__ni.vi". Did this VI come from NI? I am curious where you got it from; I couldn't figure out how to get this information and was happy to see this VI in your API. Thanks, Shawn Walpole

Hi Jakub, I had a somewhat similar situation, and I'll explain what I did in case it is helpful. I used a LabVIEW class hierarchy and then dynamically loaded the needed classes. This worked well in that I could write code using the base class and not worry about which particular implementation was needed. In the "Cluster, Class, & Variant" palette of the functions palette there is a "Get LV Class Default Value.vi" that I used to dynamically load the class I needed. I then would unflatten a string representing the configured class into the dynamically loaded default value. In my case, the classes were always runnable because all the classes only depended on VISA. In your case some classes would be broken if the appropriate driver wasn't installed. As long as you didn't load these classes, I think you would be alright, but you might want to verify that. Also, if you are building your code into an executable then you'll need to make sure all classes are runnable on the computer you are building from. As far as best practices goes, I designated a directory that was for my classes that the main program would scan from. I could then allow the user to pick from a list of what class to use. I ended up building this code into an executable. The dynamically loaded classes were part of the build as well. Because my classes and the executable could call common code, I ended up having the build specification mimic the file structure I used for development instead of putting all the code into the exe. This gave me a small exe with lots of vi files in folders with the block diagrams removed. I don't know if this is a good practice, but it seemed to make my life easier when the classes needed to load their subVIs. I hope this helps. I know some developers aren't that big into classes, but they have worked very well for me when I've used them. I'll be curious to see what solution works best for you. Shawn Walpole

A type def for a ring only defines the datatype (whether the ring is I32, U8, or whatever). So even in the development environment I don't see how updating the typedef itself will update the many callers that reference that typedef. It you make it a strict typedef, then it will include the items, but then the "Strings[]" property will not work as the previous poster said. So I'm not sure how it is working in the development environment. You might want to double check that it is updating all instances of the Text Ring and not just the one instance that you have opened the reference to. I think the reason that it works in the development environment but not as a built exe is that the path to the file of ring items has changed. Of course this is me guessing. I don't know of any way to update ring items other than either 1) Obtain a reference to each text ring control and update each one individually. or 2) Make an XControl that is a text ring that will update itself from a file.

In LabVIEW 8 and later there is a better way to scan a string into a time. Use the "scan from string" primitive with a format string such as "%.3T" or "%<%H:%M:%S %m/%d/%Y>T". LabVIEW help has more information about format strings for time. See the topic "Format Specifier Examples" for more information. Granted, it still would be nice for a Scan time string function in LabVIEW. However, with the above feature, it would be easy to make.