Integration with Seapine Surround SCM

[klessm1]

I have also posted this on the NI website, but I know you can get answers faster on this site.

I am wondering if anyone else ran into this issue (probably not because most of you use SVN).

I am getting an error when trying to configure LabVIEW 8.5 to use Surround SCM version 5.0.4, and their new beta version 2008.0.25. I also get the error when just trying to make a dll call using the call library function (after I point to the dll and the function it gives the error). I have used two computers, and LabVIEW will load perforce and vss just fine through the options window. I also have TestStand on the systems and it integrates fine with both versions of the Seapine Surround SCM client. I tried a couple of different installation types (with and without the JRE) with no luck. I get two different errors when I run the two different versions, but they are similar types of errors.

The errors are attached.

I looked into if the dlls need to be registered, but I get the error that they don't have a register entry point, so they probably are not supposed to be registered. I do have the path for the dlls in the environment variables (put there by the installation of surround). The only thing I could maybe think of is somthing needs to be setup in LabVIEW to recognize the dll links. Like I said, no problem with TestStand 4.0 linking to either version (I believe it calls the same dll).

The dll in question is: Surround SCM SCCI.dll

That is the dll that is pointed to in the registry.

Final Notes:

The nice thing about Surround is that it allows you to set the working folder for the lowest project to the root (c:\). This allows me to contain the project specific code as well as the reuse code (user.lib) in the same repository. Therefore allowing me to control all of the code in my project through the LabVIEW project window without having to change the project settings for the SCC. VSS also allows this, but I do not really want this to come to that (size limitations, no atomic commits :thumbdown: ).

I was not able to get Perforce to allow me to set the root project to C:\. I did test out subversion, but it took me quite awhile to set it up (even without apache). I also could not see how to capture revisions of a release for a LabVIEW project that calls reuse code outside it's project directory. Would you just record the global version and save the names of all of the VI's (and TestStand sequences) called by the project? To restore that version of the project on your system you would get individual files per the revision, or would you get the entire repository based on that global revision? Help me out here almighty Subversion masters. :worship:

Thanks for any inputs.

[Rolf Kalbermatter]

QUOTE(klessm1 @ Oct 5 2007, 11:43 AM)

I have also posted this on the NI website, but I know you can get answers faster on this site.

I am wondering if anyone else ran into this issue (probably not because most of you use SVN).

I am getting an error when trying to configure LabVIEW 8.5 to use Surround SCM version 5.0.4, and their new beta version 2008.0.25. I also get the error when just trying to make a dll call using the call library function (after I point to the dll and the function it gives the error). I have used two computers, and LabVIEW will load perforce and vss just fine through the options window. I also have TestStand on the systems and it integrates fine with both versions of the Seapine Surround SCM client. I tried a couple of different installation types (with and without the JRE) with no luck. I get two different errors when I run the two different versions, but they are similar types of errors.

The errors are attached.

I looked into if the dlls need to be registered, but I get the error that they don't have a register entry point, so they probably are not supposed to be registered. I do have the path for the dlls in the environment variables (put there by the installation of surround). The only thing I could maybe think of is somthing needs to be setup in LabVIEW to recognize the dll links. Like I said, no problem with TestStand 4.0 linking to either version (I believe it calls the same dll).

The dll in question is: Surround SCM SCCI.dll

That is the dll that is pointed to in the registry.

Final Notes:

The nice thing about Surround is that it allows you to set the working folder for the lowest project to the root (c:\). This allows me to contain the project specific code as well as the reuse code (user.lib) in the same repository. Therefore allowing me to control all of the code in my project through the LabVIEW project window without having to change the project settings for the SCC. VSS also allows this, but I do not really want this to come to that (size limitations, no atomic commits :thumbdown: ).

I was not able to get Perforce to allow me to set the root project to C:\. I did test out subversion, but it took me quite awhile to set it up (even without apache). I also could not see how to capture revisions of a release for a LabVIEW project that calls reuse code outside it's project directory. Would you just record the global version and save the names of all of the VI's (and TestStand sequences) called by the project? To restore that version of the project on your system you would get individual files per the revision, or would you get the entire repository based on that global revision? Help me out here almighty Subversion masters. :worship:

Thanks for any inputs.

LabVIEW 8.5 does use the QTLib for something in its user interface or whatever but I'm not sure for what. Look in your LabVIEW 8.5 directory to see those DLLs. The problem you are having is that your Surround SCC software uses that library too but not the same version as LabVIEW 8.5 uses. That gets you into the so called DLL hell. LabVIEW already has loaded it's own QTLib DLLs when the Surround SCC client gets loaded. This client also wants to load his QTLib for some functionality but since Windows sees that that DLL is already loaded into the current process it will simply attempt to have this client library link to LabVIEWs version of the DLL. And that goes wrong since those libraries are not binary compatible, something Unix shared library developers never usually worry to much about since they are used to versioning of the shared library name to resolve such issues.

I'm afraid you run into a roadblock with Surround and LabVIEW 8.5. As I have no idea for what LabVIEW 8.5 brings its QTLib stuff with it I can also not help you with any ideas if and what would have to be disabled in LabVIEW in order to not have it load QTLib, if anything can be disabled. For its UI Widget stuff I can't really imagine that they replaced the entire existing windows manager code to use QTLib instead of continuing to use their own already implemented window management code, so what QTLib really is good for in LabVIEW 8.5 is really a secret to me.

Rolf Kalbermatter

[klessm1]

QUOTE(rolfk @ Oct 7 2007, 11:49 AM)

LabVIEW 8.5 does use the QTLib for something in its user interface or whatever but I'm not sure for what. Look in your LabVIEW 8.5 directory to see those DLLs. The problem you are having is that your Surround SCC software uses that library too but not the same version as LabVIEW 8.5 uses. That gets you into the so called DLL hell. LabVIEW already has loaded it's own QTLib DLLs when the Surround SCC client gets loaded. This client also wants to load his QTLib for some functionality but since Windows sees that that DLL is already loaded into the current process it will simply attempt to have this client library link to LabVIEWs version of the DLL. And that goes wrong since those libraries are not binary compatible, something Unix shared library developers never usually worry to much about since they are used to versioning of the shared library name to resolve such issues.

I'm afraid you run into a roadblock with Surround and LabVIEW 8.5. As I have no idea for what LabVIEW 8.5 brings its QTLib stuff with it I can also not help you with any ideas if and what would have to be disabled in LabVIEW in order to not have it load QTLib, if anything can be disabled. For its UI Widget stuff I can't really imagine that they replaced the entire existing windows manager code to use QTLib instead of continuing to use their own already implemented window management code, so what QTLib really is good for in LabVIEW 8.5 is really a secret to me.

Rolf Kalbermatter

Thanks for your reply. For some reason I wasn't able to reply on my PC at home over the weekend. My browser settings must be hosed. Someone answered from the NI forums as well with the same diagnosis. I was able to replace LabVIEW's QTLib with Surrounds newer version and was able to get it to work. Now I have no idea is that is going to effect something in LabVIEW (something I haven't used yet). I have a support case with NI for this to see if they have any idea if the 4.3.0.0 version can be used, or if there is some way to trick LabVIEW and Surround to use their respective QTLib's.

Thanks for the info!

[Rolf Kalbermatter]

QUOTE(klessm1 @ Oct 8 2007, 11:46 AM)

Thanks for your reply. For some reason I wasn't able to reply on my PC at home over the weekend. My browser settings must be hosed. Someone answered from the NI forums as well with the same diagnosis. I was able to replace LabVIEW's QTLib with Surrounds newer version and was able to get it to work. Now I have no idea is that is going to effect something in LabVIEW (something I haven't used yet). I have a support case with NI for this to see if they have any idea if the 4.3.0.0 version can be used, or if there is some way to trick LabVIEW and Surround to use their respective QTLib's.

Thanks for the info!

The best bet is always to use the newer version of a lib if you get such a conflict but it will not always work. The newer version may change interfaces (yes it's a bad thing to do, but it's very easy to if the developers don't watch very extremely carefully) and then crash the application which was compiled to the older lib. But as long as it seems to work, I would definitely try it.

If you get to know what they use QTlib for, I would be really curious. I could try a disassembler but don't feel like doing it nor have I the time at the moment.

Rolf Kalbermatter