DLL with Tab Control (new control in CVI8) needs CVI8 run-time engine support

[jacky Wang]

I built a DLL with a Tab control UIR in CVI8.0 (Tab control is a new control in CVI 8), then created a step type in Teststand3.1 by specifying its module adater as that DLL. This step type behaviors well on my Laptop with CVI8.0 and Teststand3.1. However, when I want to use it on another laptop with Teststand3.1 and CVI7.1 (no CVI8.0 run time engine installed), there comes problem.and after I installed a CVI8.0 run-time engine, it's OK.
But, since it's just a DLL. theoretically speaking I don't think there's no need to install a cvi8 run-time engine, but actually not.


Thanks!
Jacky

[jacky Wang]

I have quite a lot DLLs built in CVI7.1 and a new DLL buit in CVI8.0 with a new Tab control UIR. My PXI is installed with Teststand3.1 and CVI7.1 full development software. You know in order to use that new DLL, I have to upgrade CVI runtime engine to CVI8.0 (no CVI8 full development package). However, I just hesitate to do this, because I don't know whether this will impact the proper operations on other DLL built in CVI7.1.
Besides, I have some other step types in Teststand3.1 using the CVI adapter. I don't know whether this step types will be impacted after I installed new CVI8 runtime engine

[LuisG]

Jacky,

Upgrading the CVI Runtime Engine should not impact your existing 7.1 applications. NI always strives to make the runtime engine fully backwards compatible. Which is not to say that every now and then issues don't creep up. But in general, the expectation is always that there should be no behavior change. Also, keep in mind that several other NI applications also install the CVI Runtime Engine, which means that even if you don't explicitly upgrade it yourself, it might happen anyway without you realizing it, as you install some other software.

Luis
NI

[rolfk]

---

@jacky Wang wrote:
I built a DLL with a Tab control UIR in CVI8.0 (Tab control is a new control in CVI 8), then created a step type in Teststand3.1 by specifying its module adater as that DLL. This step type behaviors well on my Laptop with CVI8.0 and Teststand3.1. However, when I want to use it on another laptop with Teststand3.1 and CVI7.1 (no CVI8.0 run time engine installed), there comes problem.and after I installed a CVI8.0 run-time engine, it's OK.
But, since it's just a DLL. theoretically speaking I don't think there's no need to install a cvi8 run-time engine, but actually not.

---

Actually CVI DLLS do need the runtime system too. A CVI DLL does not link the entire runtime engine in (I think it did that once back in CVI 3.x days for executables - no CVI DLLs at that time - but at that time the CVI runtime system was more or less a single file. Nowadays it is a whole bunch of DLLs, support files and such, so linking this into your DLL would be not very convinient, bloathing your DLL to multi MB monsters, apart from the fact that some of the support files are not easily embedable in an executable file (which a DLL in fact is too, just with a different startup routine).

Rolf Kalbermatter

Message Edited by rolfk on 05-16-2006 10:24 AM

[mvr]

rolfk is correct.  It is best to install the CVI runtime on any system where you are using a CVI dll.  There are some CVI functions that run fine without it, but sooner or later you will probably use one that requires it.  This is not really that uncommon, visual basic and matlab come to mind as other programs that require a runtime library install for executables or dlls.  I am thankful that CVI does not require a per system or per user runtime license for application distribution.  The costs of adminstration and hassles of locating funding when using per system licenses can severely limit the ability to distribute utility programs and applications.