Programmatically find IVI software module path? - or dynamically instantiate class from module name?

[Believer]

Hello All,

Anyone know how to programmatically find the path of a registered IVI software module (found under Advanced \  Instrument Software Driver Modules) ?

I can enumerate through the config store and get the names and filenames of each module (e.g. module.dll), but not the full path. It's not necessarily going to be "Program Files\IVI\bin".

I'm sure that it has something to do with the registry...

I really want to be able to create an instance of a chosen module class at run time (an IIVISwtch class), but I need the actual derived class to do it, and I figured that if I could find the module path, then I could load the assembly and go from there.

If you know of a better way then I'd be very grateful!

Thanks,

Ronnie

[Makoto]

You can acquire the IVI standard directory from the registry:
IviStandardRootDir variable (REG_SZ type) under HKEY_LOACL_MACHINE\SOFTWARE\IVI. 

Every IVI driver binary (DLL) must be placed under the BIN subdirectory.  Also, the BIN directory is added to the PATH environment variable by installing IVI Shared Components, therefore DLLs placed there can be implicitly loaded when you omit "full path" for LoadLibrary() call.

[z_haider]

Believer,

It's not clear from your post if you are using IVI-C or IVI-COM technology. If your program uses IVI-C class drivers provided by National Instruments, then you do not need to access the config store directly. The class driver will automatically find and load the IVI-C specific driver using the Logical Name you provide to the Initialize function. If the path specified in the software module is not a full path, then the DLL must be present in the Windows system path (the %PATH% environment variable). Note that you cannot directly use an IVI-COM driver with an IVI-C class driver.

On the other hand, if you are using an IVI-COM driver, then all you need is the progID (or class ID) of the COM driver. You do not use/need the DLL path. You can either create an instance of the COM driver your self (using CoCreateInstance with the progID) OR you can use the IVI Session Factory to obtain an IUnknown* to the COM driver using a logical name. The IVI Session Factory is part of the IVI Shared Components and is installed in the IVI/Bin directory.

Good luck,

z_haider

[Believer]

I appreciate your replies Makoto and z_haider. Yes this is for a COM dll - and no - the DLL is not necessarily going to be in the IVI\bin directory because during development it can be anywhere, but of course it is still registered by regsvr32 into the registry.

Looking at what's returned from the ConfigStore for the ProgID it's something like: "XComDriver.XComDriver".

I'd like to do this in C#, but I'll try your suggestions for CoCreateInstance and/or using IUknown* in C++ first.

If you had some example code that you could post which uses one of these methods and shows how to get to eventually get the IIviSwtch object - that would be great. Meanwhile I'll dig around to try and find an example myself.

Thanks again.

[Believer]

Here's how I managed to solve it in C#:

// using System.Runtime.InteropServices; string strProgID = getProgIDFromConfigStore(strName); Type dcomType = Type.GetTypeFromProgID(strProgID, true); Object dcomObj = Activator.CreateInstance( dcomType ); // casting to interface is like legacy QueryInterface : IIviSwtch mySwtch = (IIviSwtch)dcomObj; // simple class casting :

// YourClass yourInst = dcomObj as YourClass;

mySwtch.Initialize(strRes,

false, false, strOptions);

[geodo]

How can I discover the ProgID using IVI-OCM??

Is the progIP common for a class driver??

i would to know it before??

Thanks

[geodo]

Error description is: IIviSessionFactory: Session CLSID (7e65c8d3-046f-42d3-ba3f
-4c7c31925df5) not registered

Its my error

Anyone know how to solve it??

Thankssss

[Makoto]

To find the prog-id string of your IVI-COM driver, use NI-MAX and browse for the Software Module (or driver identifier string) then check its property information deeply. There must be prog-id info of the IVI-COM driver.

As for class factory error of GUID "7e65c8d3-046f-42d3-ba3f-4c7c31925df5", this GUID looks like the IVI-COM driver that you are trying to use. (I could not find this GUID on my PC, which already install IVI components.) Try to search this GUID value in your system registry by REGEDIT.exe to see if the component is registered or not. If not found it looks like your IVI-COM driver is not properly installed. In this case, you should once uninstall the IVI-COM driver then install it again. Doing so may fix the registry problem.

[geodo]

Hi Makoto, thannks

The sense of  my question is

If there is a progId only for use in software and be able to communicate with any DMM (for example) of all vendor that connect to the network as long as it support the standard, of course.
Or if, on the other hand, the user should introduce a ProgID speciffic to operate the software for each different instrument, even in the same class

Excuse my level of English.

Greetings and thanks

[Makoto]

As for IVI-COM architecture, there is no progID exist that can be commonly used for a specific class (such as IviDmm or IviDCPwr...). In other words, you can never create an object instance of "class driver". There only thing that does exist is "class interface". (This is very different part than IVI-C.)

To create interchangeable app, there are two approaches.

(1)This assumes that your app already knows instrument list that may be supported in your app. In this case, your app may create an instance of specific instrument driver type (with exact driver identifier such as Agilent34401), then typecast the IAgilent34401 interface to IIviDmm. Although all the instrument access can be through the IIviDmm, your app will have an assumption of specific instrument model/driver.

(2)This does not have any assumption of specific instrument model in your app coding. First you must create a Logical Name entry that will be used as virtual instrument name, such as "myinstr". This can be done by NI-MAX or Agilent IO Connection Expert. Then create its linkage to Driver Session, Software Module, and Hardware Asset. This configuration is done outside your app, and the Logical Name will have enough info about what specific instrument driver to be used and what VISA address is to be used. Once Logical Name is created, your app must start from creating IVI Session Factory object. The object's CreateDriver() method only takes the Logical Name, and create driver object instance of what configured in NI-MAX or Agilent IO. The example is as follows:

IIviSessionFactoryPtr spSf(__uuidof(IviSessionFactory));
LPCWSTR pLogicalName = L"myinstr";
IIviDmmPtr spDmm = spSf->CreateDriver( pLogicalName);
spDmm->Initialize( pLogicalName, TRUE, TRUE, L"");
...
spDmm->Close();

This approach can make your app perfectly isolated from specific instrument drivers. Mind that the CreateDriver() method takes Logical Name that was configured in NI-MAX, not progID. (The progID of specific instrument driver is internally used in the Session Factory to load the correct driver DLL, but you don't have to be aware of it.)

このメッセージは　04-16-2008 06:08 PMに Makoto が編集しています。