Is there any way to seperate MFC from nivisa.h?

[rtorchia]

I can (sort of) understand why you would tie CWui components to MFC (Component Works++), but I don't understand why including nivisa.h brings in MFC pieces. I have an Active Template Library (Com server) project where I want to use nivisa.h. Has anyone used nivisa outside of MFC? It soundd like I may just want to use visa32.dll directly, instead.

[drohacek]

The datatypes are the reason that the Measurement Studio for C++ components require MFC. One of the design goals of these libraries is to make it easy for you to pass data between the acquisition, analysis, and presentation portions of your applications. The CNiVector, CNiMatrix, and CNiString data types are the primary means for doing this. These classes are MFC-based so that they integrate directly with the MFC application development framework to provide functionality such as CArchive serialization via the CObject base class.

It is possible to use ATL and MFC together in an application. There is an MSDN knowledge base article that describes how to do this. If you are reluctant to include MFC in this server because you do not want your application to refere
nce the MFC run-time DLL, you can avoid this with Measurement Studio 6.0.

Measurement Studio 6.0 includes static libraries that link to the static (non-DLL) version of MFC. Specify in your ATL project that you want to include MFC as a static library and the compiler will automatically pull in the correct version of the Measurement Studio libraries. Note also that the linker will discard unreferenced symbols so that although you will be linking to static MFC, very little of it will actually end up in your server.

Another thing to note is that you cannot link to static MFC if your application uses the Measurement Studio UI controls because the ActiveX controls themselves internally link to the MFC DLL.

Please post a follow-up if you have other reasons or requirements for not including MFC in your application. This kind of information is valuable to us in deciding the future direction of this and other products.


David Rohacek
National Instruments

[rtorchia]

ATL and MFC do NOT work well together in a COM server application, especially if you want to implement DCOM. I have attempted this in the past. Also, if you want a light weight com application (ActiveX), without the overhead of MFC, you would just use ATL (its original intent). I think it was a bad design decision on NI's part to link its nivisa control with MFC. On a similar note, will nivisa work on a parallel port interface? If so, how do you read and write to control and status registers? I could not find any parallel port VISA sample code.

[drohacek]

For the purposes of NI-VISA, you reference your parallel port through the Serial interface. You can use CNiVisaResourceList to determine the symbolic name of your parallel port. This is typically ASRL10::INSTR.

I am not certain what you mean by reading from and writing to the control and status registers. Are you referring to the registers on your device?

I want to clarify about linking to static MFC. When you link to a static library, the Visual C++ linker retains only those symbols that you reference in your program. You can therefore include the NiVisa components that link to static MFC without assuming the overhead of the entire MFC library. The most your application would actually contain could be CObject and CString. In reality only
those functions that are actually called make it into your server. In all probability you would end up with only a couple of CString member functions that we use inside the libraries. I would anticipate that this would not be much overhead relative to the size of your server. It might be of interest to note that in the next version of Visual C++, ATL and MFC use the same string class.

It certainly is conceivable that there are circumstances under which you do not want to use the Measurement Studio data types that leverage MFC. If this is such a circumstance I recommend that you use the C API directly. You just need visa.h and visa32.lib. You can find these in your VXIPnp directory.

David Rohacek
National Instruments

[rtorchia]

Thanks for the MFC/Measurement explanations.

What I was referring to by reading and writing to registers are the different locations that need to be read for parallel port communication. For instance, in order to check if the Rdy bit is set, you need to read a byte from the status port (i.e. inp(0x379)), and verify the bit 4 is set. In the old DOS days, you peek and poke to PC ports all you wanted, but NT has protection from this sort of thing. Only drivers have this sort of direct access to ports. Does VISA allow me to Peek and Poke to parallel port addresses? We are currently using AccessHW to do this, but would like a better abstraction layer. Also, a parallel port communicaton sample using VISA would be incredibly useful.

[drohacek]

VISA does not provide this kind of access for the PCI and ISA buses.

You can use VISA to read data from and write data to the parallel port using the ASRL[]::INSTR resource type. This communication works like communication with serial or GPIB instruments.

Currently the only thing Measurement Studio provides you to help with this type of communication is the CVI utility library inp and outp functions. There is overhead in this approach in that it requires that you reference the CVI run-time DLL in your application. The CVI run-time DLL intaller installs platform-specific device drivers that the inp and outp functions use. This does not provide you anything more than you already are getting with AccessHW.

David Rohacek

National Instruments