labview 7.1 runtime and Measurement Studio 6

[fakeleft]

I have a VB6 app that uses a Labview 7.1 - generated dll (third-party) and CWGraph and other controls from Measurement Studio (7.0) Enterprise Support for Visual Studio 6.  This requires the 7.1 runtime on the client (yet the VB6 controls are 6.0).  I get the "30 day evaluation" message on client machines (not on the development machine), which I assume is due to the app trying to use 7.0 controls that come with the 7.1 runtime, though I could be wrong.  What's the correct setup to fix this? (i've looked in the forums, but the threads about the 30 day license don't seem to address my situation).

Thank you,
raphael

[Jon_M]

Hi raphael,

Does this still occur when deploying to a target machine when you don't install the LabVIEW 7.1 runtime engine? I'm curious to see if this still happens without the RTE, though I realize that your app is dependent on the RTE for your dll to function, I want to see if it still happens in that scenario.

What should be occurring is that the licensing info should be embedded into the executable so even if the eval license is on a client machine, the executable should ignore that and use the licensing info it contains.

[fakeleft]

Hi Jon,

Thanks for replying.

So I did a few more tests:

1.  Simple VB executable with a CWgraph control on a form, running on a freshly installed win2k vmware virtual machine.  Ran no problem.

2. I then took a build of the real app and installed on the same virtual machine (i was previously copying and registering cwui.ocx in my installer (not sure why) - i've removed that from the installer, given the results above ).  Running the app produced a message asking for the 7.1 runtime, as expected.  I installed it, and things ran fine, no evaluation message.

However:  I have a desktop machine that I used for development previously.  It had Labview 7.0 and Measurement studio installed, plus the 7.0 followed by the 7.1 runtime.  I uninstalled everything from add/remove programs, then followed the same steps as on the clean virtual machine.  The evaluation message appears.  It seems the Labview uninstallers aren't removing everything they should.  The client's machine has a similar setup, and it responds the same way.  I'd hate to ask him to wipe his hard drive...

[Jon_M]

He should just be able to unregister the ocx (the LabVIEW and Measurement Sutdio uninstallers don't always unregister the ActiveX components on the OS) by following the info in the two KBs here and here and he should be good.

[fakeleft]

I tried the License Fixer on my test machine.  It found an evaluation license for "User Interface controls 1.0 Demo".  I get a "Run-time error '9': Subscript out of range" when trying to revert.

I've also gone through the registered components shown by OLE Viewer (after uninstalling the 7.1 runtime) and written a batch file to unregister any NI components I recognize.  It looks like this:

regsvr32 -u -s "C:\Program Files\National Instruments\Shared\USI\Bin\Cit43drv.ocx"
regsvr32 -u -s "C:\Program Files\National Instruments\Shared\USI\Bin\CitadelDL.ocx"
regsvr32 -u -s "C:\Program Files\National Instruments\Shared\USI\Bin\GUSI.ocx"
regsvr32 -u -s "C:\Program Files\National Instruments\Shared\USI\Bin\GfSFSI.ocx"
regsvr32 -u -s "C:\Program Files\National Instruments\Shared\USI\Bin\SQLDriv.ocx"
regsvr32 -u -s "C:\Program Files\National Instruments\Shared\USI\Bin\STreer.ocx"
regsvr32 -u -s "C:\Program Files\National Instruments\Shared\USI\Bin\gfsaop3.ocx"
regsvr32 -u -s "C:\Program Files\National Instruments\Shared\USI\Bin\hBrowXr.ocx"
regsvr32 -u -s "C:\Program Files\National Instruments\Shared\USI\Bin\iBrowXr.ocx"
regsvr32 -u -s "C:\Program Files\National Instruments\Shared\USI\Bin\nicitusi.ocx"
regsvr32 -u -s "c:\winnt\system32\cwui.ocx"


The license fixer still shows "User Interface controls..." after running this.  Any idea what ocx file or registry entries need to be knocked out to clear this?

[Jon_M]

The ocx that the User Interface controls is pointing to is the one located at c:\winnt\system32\cwui.ocx, however I don't know what registry key its associated with.

If after unregistering the ocx, deleting it and rebooting doesn't do the trick, you might just want to remove all NI software, delete the National Instruments trees in the registry under HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER, delete the Program Files\National Instruments directory and reboot. This should start you off with a fresh slate. Somehow the eval copy of the control got installed over the top of the licensed copy of the control on that machine. We include eval versions of the control with most of our drivers so if you installed the NI-DAQmx or any other driver that is probably where the eval copy came from. The License Fixer is the most common way of reverting the correctly licensed Measurement Studio copy of the controls.

[fakeleft]

Hi once again Jon,

Sorry I keep on coming back to this at such irregular intervals. I think I've narrowed down the problem. It seems that things work fine with early binding, but not so with late binding (of cwanalysis controls). Attached are 2 sample vb projects to show you what I'm doing. I assume there is a license of some sort that has to travel with the app? I don't see anything in the distribution instructions.

I don't think it's that big of a deal for me to change things to use early binding, but I'd still like an explanation/fix if there is one.


Thank you,

[Jon_M]

HI raphael,

We don't have any documentation on this as its how Visual Studio ActiveX licensing works. We have an example that shows how to do this correctly here and some additional information is located here.