ViServer OpenLibrar​y gets Corrupted Memory error

Question

I am trying to integrate LabVIEW into our ClearCase build process. At a basic level, we store all vis in libraries, we plan to make increased use of LabView projects.
Right now the team is using LabView libraries without projects. I have access to some of them. I can open them using LabView 8.51. A warning is issued for objects found in different places, but the vis in libraries can be opened. However, when I try to execute this code:
Set Args=WScript.Arguments
llbName=Args(0)
WScript.Echo "Looking for vis in library "& llbName
Set lvapp=CreateObject("LabVIEW.Application")
Set llb=lvapp.OpenLibrary(llbName)
Wscrpt.Echo "Found library "&llb.Name
this is what happens:
D:\Data\builds>cscript get_vis.vbs Z:\tse\Projects\NEXTGEN\Tests\CurrentLimit.llb
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.
Looking for vis in library Z:\tse\Projects\NEXTGEN\Tests\CurrentLimit.llb
D:\Data\builds\get_vis.vbs(5, 1) LabVIEW: LabVIEW:  Memory or data structure corrupt.
Looking over the object model, the only way I can see to get a list of vis in a LabView library is to create an instance of that library using the OpenLibrary method of Application.

Answer 1

Hi Bob,
Good call. It is always important to start with the requirements!
If you use a vi server it means that the LabView is being driven from the outside application, not the other way around. I am trying to drive LabView via the ActiveX interface. Most people do the opposite: inside LabView (the main application) access other software via ActiveX.
I am writing a process control system for our test engineers to automate the entire software development cycle by bringing together our project tracker (in-house) and our configuration management software (ClearCase) in such a way that no test engineer needs to know the arcane ClearCase commands, and all development work is done on branches that must be merged back to the main line for others to see the changes.
For projects larger than something small, or projects where multiplie developers must work on the whole system together, this branch - develop - merge idea is key. It enables developers to be very productive without stepping on each other's work.
The section "Source Control" in this document http://zone.ni.com/reference/en-XX/help/371361D-01​/lvdevconcepts/configuration_management/ refers to the concept of reserved checkouts, i.e. if I want to change a file I check it out reserved, so no one else can toudh it. This is an immature concept that does not work with more than 2 or 3 developers in a small team working on very focused projects. Branching eliminates the need for this coordination, but it then demands a robust way to merge changes.
ClearCase knows how to merge text. I have that part almost ready to release now. ClearCase cannot merge binary files, it can only recommend the latest version if that can be clearly determined, otherwise it is up to the developer to tell ClearCase what the latest version is, or to check in yet another version that is known to be the latest.
LabView vis are binary files. Since that is our main programming language, we cannot simply take an entire library or project that may have been worked on by 6 people over a 3 week period and wave a wand saying that a particular version is the latest. We must be able to do these things:
Detect that more than one person has changed the object. This ClearCase can do at the library or project level with no help from LabView.
Provide a list of what individual vis have changed. This must be done in LabView. I had wanted to get the list of all vis in a library or project by automating LabView, then automate the stepping through the list using the command line merge tool (lvmerge.exe) to detect vis that were really different.
Assist the developer to merge the changes by cycling through the vis that have changed automatically, opening up the vis in the merge tool so that the developer does not have to tediously click through the file-open nonsense for dozens of vis. The merges must be done in LabView, the sequencing could be automated externally or internally.
Mark successful merges. This is done in ClearCase.
In summary, the ability to merge individual vis is a non-starter when NI itself strongly recommends projects and libraries for organizing projects. To put it in simple terms, it is like me telling you I have this fantastic tool for merging text files, but the entire body of source code must be stored in zip files. So, if you want to use my tool, you must manually open the zip file, extract the text file, then work with it and re-zip it when done. You would not be happy.
Best regards,
Bill