Specifying the path to a dll

[tom_kreutz]

I'm new to CVF and am having trouble understanding how to build and use a dll.

I built a dll in one project, and a main program in another. By changing the Windows 2000 Path environmental variable (to the dll debug directory), I got the main program to run, but that is an ugly solution.

Is there a simple way to set the path to the dll in the workspace of the main program project? (I tried, for example adding the path to Tools MenuOptions... Directories tabShow directories for Executables, but that didn't seem to do anything. What DOES it do, anyway?!) The Programmers Manual suggests a whole raft of things in the chapter entitled "Building Executables that Use DLLs", most of which I don't understand, and don't work anyway.

What actually happens when I import the .lib file into my main program project (via Project menuAddFiles)? It doesn't appear that I need to do this to get the main program to work properly.

My apologies for such silly questions; I find the documentation for CVF fairly impenetrable. (Are there any good books or reference materials that I should read?)

Many thanks,

Tom

[rahzan]

The easiest way is to copy the DLL to the caller's folder.

If that is too much work, you can set the location of the output of the DLL project under
Projects--Seting--Link--Output file name

Tim

[tom_kreutz]

> What actually happens when I import the .lib file into
> my main program project (via Project menuAddFiles)?
> It doesn't appear that I need to do this to get the
> main program to work properly.

Whoops! I'm wrong. It DOES matter! What does this step do?

[rahzan]

You can think of the LIB as the _Interface_ to the functions of the library While the DLL holds the actual contents of the routines in the library.

An interface is basically, the names of the routines, the type of procedure (subrputine, function) and the name, sequence and the types of the arguments.

Having these but not the underlying code satisfies the need from the caller app to fiish the build process and acts as a kind of placeholder until the actual code is supplied in the DLL at runtime.

For a STATIC library the LIB file contains BOTH the interface and the implementation, therefore it is NOT possible to effect the code changes in the library without recompiling the whole app.

With a DLL you can change the code as long as you do not change the interface. Then you can simply replace the old DLL with a new one and leave the caller app alone.

STATIC libs are more cumbersome but typically result in faster execution, because the whole project is likely to be better optimized when all code is available.

Tim

[Jugoslav_Dujic]

I'd just second Tim's suggestion to change the path to .dll on dll's ProjectSettingsLinkOutput file name. If you copy the dll instead, you're likely to be surprised once when you forget to do it. For example, it's really funny to debug old copy of the .dll while looking at source of the new copy.

I doubt you'd get any better optimization with the static library, as the compiler (not the linker) doesn't know about its existence to be able to do anything smart, and the linker is dumb anyway. The only performance cost for using dll's is one-time dll loading.

Jugoslav

[tom_kreutz]

Dear Tim and Jugoslav,

Thanks very much for your very helpful replies!

Tom