How does Visual Basic know about mxDAQ?

[booherbg]

I'm sorry if this is very common knowledge, but I can't figure this out anywhere. I am using Visual Basic 6.0 with the NI USB-6009 DAQ.  I am trying to develop a way to tell if the NI support is installed on a system - and disable it if not (instead of crashing).  This is so that we can run a software application on a computer where the DAQ is not and will not be installed. The problem is that I was given an existing VB project to modify and I don't understand how VB knows about the DAQ functions - like DAQmxCreateDIChan(), for example.  I can't find any NI .dll files referenced in .bas file, nor are any custom controls included.  If I start a new VB project, the function DAQmxCreateDIChan() is not recognized. This means that somewhere in this current project there are function definitions (or something) for the NI DAQ api.  I'm sure I'm just missing something very basic.

Thank you in advance.

[drohacek]

The DAQmx API provides a type library that helps you use the C API in VB6. In Visual Basic, go to Project>>References. In the list box, "NI DAQmx C API" will be checked if the project has a reference to the type library.

For more information on the VB6 support, on a system with NI DAQmx installed, go to All Programs>>National Instruments>>NI-DAQ>>NI-DAQmx C API Visual Basic 6.0 Help.

[booherbg]

Thanks, that is just what I was looking for!

Is there any way I can tell if this reference is available on a machine or not? If not, would it be possible to manually make the API function calls in a .bas file and check to see if a .dll exists first?

Thanks!

Blaine

[drohacek]

You can look for nidaqmx.tlb in your Windows\System32 directory to determine whether the reference will be available to VB6 projects. Will this work for your case?

[booherbg]

Its a good start - but the problem is that when I compile this into an .exe file, and send that file to another computer, the application will crash if that 'reference' isn't found on the computer, correct?  I need a runtime way to disable the reference if the .dll is not found on the system.  Is there a method for doing this in VB that anyone knows of? Otherwise we'll have to fork the codebase of our application - one that requires the DAQ and one that doesn't.

Thanks!

Blaine

[bilalD]

The tlb early-binds the application to the daqmx dll, so the app will try and load the dll even before it hits the application's entry point. You could create a bootstrapping exe that does the driver check for you. Forking the code base would be another option.

If you want to write the declare statements yourself, you can use free tools like oleview to view the contents of the type library and create a .bas file. I could not find a tool that would automatically do that for you.

[booherbg]

You have some great ideas - thank you for your response!

If I bootstrap - How could I even access anything that would let me pass onto the main application "do not load that reference".  Is this possible?

I may try the .dll tool that you mentioned.  We only use a few functions so this may not be a big deal.  It'd allow me to see everything that is going on in front of me as well - instead of relying on a hidden menu without any interaction besides clicking a checkbox in the design environment.

Thank you for your help!

Blaine

[bilalD]

The only thing your exe would do is check for the existence of the DAQmx DLL and decide whether to load your main app (which would have to be a DLL) via some pre-determined entrypoint or provide the user with an error indicating the DAQmx driver is required to continue running the app.

[booherbg]

Thank you for the response.   The problem is that I need the software to run correctly if the DLL is not found.  The point is that there is only a very small functionality that uses the NI .dll - and sometimes the software will run on a computer that does not have the NI DAQ installed.

Thanks!

Blaine

[AndrewMc]

Hey Blaine,

Then it sounds like what you might need to do is either the option that you've already introduced - creating two separate installers, launching one or the other depending on whether DAQmx is installed (DLL is present) - or by using a technique called late-binding where you extract the DAQmx calls into its own DLL and reference it "dynamically".  Since the default behavior is to look for any dependency even if it isn't called, late-binding should allow you the option to conditionally load the DAQmx assembly.  For more information about late-binding, you can either search the web or check with Microsoft.

Hope this helps!