Leaderboard

Okay, I had to create an account to answer this. My company uses this stringent requirement to part number everything, including each individual class. As such, each class folder contains its part number. There have been plenty of occasions where the number I get is already used and I wasn't informed until after the class was developed. As such, I can and often do have a class and around 50 Vis that I'd have to move. I use to try by windows explorer, but could never get it to be pretty. Then I discovered the Files view. Original view: In here, I select the class and all its member VIs. Right click, and Select "Move on Disk..." I then find where I want to move it to, create folder if necessary, and select "Current Folder" It'll take LabVIEW a few seconds to process simple moves, to about a minute for really complicated ones. It also relinks every VI call. (If in memory) Afterward, it shows properly as moved: This has literally saved hundreds of hours vs trying to move each individual VI one at a time. We also compile our code into lvlibp libraries so other functions that would call it, calls the packed library instead. That's why we won't have issues with external "non-loaded" code attempting to find new location.

As mentioned in the NI forum, the Database Connectivity Toolkit is essentially a wrapper around an ADO ActiveX object. ADO uses an ODBC connection internally and there are syntax differences when using ODBC compared to using MS SQLServer directly: @variable declarations are not supported via ODBC.

@Mads If one does two steps at once (rename class and rename folders outside LV IDE) you run into trouble. I often find myself in the situation to do to much in one step. When having renamed a class outside of a project, I wonder if it would be possible that LabVIEW IDE tries to relink everything assuming that the new class (which the user selects as a replacement) is designed like a child class. I think you rename a class but you wouldn't change class VI names like "init", "get property XYZ", "calculate abc", "uninit", ... So LV IDE could find the right class VI for replacement in the new class. Of course new classes have new functionality. But no one can guess how and where to use it except for the architect and programmer. So new functionallity has always to be updated manually.

Man, I hope I never have to debug any of your code. A class (or VI) name should reflect what it does. I feel it is not really acceptable to compromise on this just because the IDE chokes sometimes when doing these kinds of modifications.

I always rename a class from a project, either using Save As... or Move on Disk.... In either case I also specify a new destination folder with the new name. Methods associated with the class I then move in the project files view. Yes, as mentioned above, it is necessary to delete the old, now-empty folders outside LabVIEW (from a file explorer application), unfortunately. (NI changed this for LabVIEW 2010: see "Restore 'Delete from Disk' in project Files view" topic in the Ideas forum for more details.) With TortoiseSVN (i.e., outside LabVIEW) it is possible to specify that one file is the rename of another, so that the new file will keep the old file's history. I recently joined a new organization that uses Git, and I haven't investigated how to do that with Git yet. I use the LabVIEW IDE's search and replace functionality to update the icon names on the object control and indicator names in the class methods. This is fairly straightforward, since it is pretty easy to select the VIs in the class for search scope. The process works well enough for me with too much trouble (although I don't always end up being able to link the new file to the old history), but clearly this requires more effort than it should. (I'm reasonably happy working with TortoiseSVN outside the LabVIEW IDE, but fully capable integration with source code control from the IDE would simplify these steps and reduce errors.) A few years ago someone posted a tool on LAVA designed to facilitate renaming of classes. I haven't tried it myself. This discussion points out areas where the project (failure to delete folders from disk) and version control integration (inability to rename files effectively--which requires the ability to delete folders) are incomplete in the LabVIEW IDE. It seems clear to me that a complete solution integrated with the IDE (clarification, a complete integration with external source code providers) would be quite beneficial. (OK, the fact that some people are seriously suggesting not to rename classes is a pretty big red flag here.) When it comes to renaming classes used in multiple projects, there are fundamental limitations, since an unopened project does not "know" what happened to a class also used in another project. If one can reasonably create a project with all callers, that works, but that isn't always practical. Putting classes in project libraries helps (the library, shared between projects, tracks changes internal to it, instead of multiple projects), where this is appropriate.

Maybe you should get in touch with your NI sales rep. He'll help you figure out if TestStand is the right tool for your application.