Quote Originally Posted by mflum7 View Post
The error code is as follows on Win 8 or XP (using VC++ 2005):

"Run-time error '48: File not found: DLL2.dll
Ok, as far as I see, there's nothing wrong with the C-Code - and it's also exported
as __stdcall - and your Declare line in VB6 is also OK.

So it is a I guessed, and the Error-Description above should have given you the same idea.

If a File is not found, named Dll2.dll - then you didn't even reached the point yet,
where VB6 is trying a "jump into your declared function".

With VB6 Declare-Lines you define a "Job-Description".

And other than with typelib-defined API-Calls (where the *.tlb-defined Dll is early loaded,
at Startup-Time), VB will use "delayed loading" of the Dll-File itself, at the first reached
Position in your Code, where the Declared Function is about to be used (called).

The first thing VB does (under the covers), when it reaches such an external
Function-Call-definition, is to look up in you Declare-Line, which Dll-file to load
(with the goal to retrieve a "Library-Handle" for it).

The API-call which is used under the covers for that is: LoadLibrary

If VB cannot find the Dll with its own, internal Call to LoadLibrary, then the
Error you've reported is thrown at you...

If it was able to load the Dll-File, then the retrieved Dll-Handle is cached for
later usage (of other declared calls on the same Dll-Name), and the next
hidden API-call is performed: GetProcAddress
GetProcAddress is using the earlier retrieved LibHandle in conjunction with
the "FunctionName-String" you gave in your Declare-Line - in case the
Name of this function is not found in this already loaded library, you will
get a different kind of error, which clearly states also that.

In case of a successful retrieval of the Function-Address (per GetProcAddress),
VB will also cache this Function-Pointer - and only then proceeds with "jumping
into the Dll-Code", calling the externally defined function (with again different
Errors, when the Parameter-Count - or -Types didn't match).

But as said, you didn't even reached all those later points, the only thing you
will have to fix is the problem, VBs internal LoadLibrary-Call has, in finding
your Dll2.dll.

As I said earlier - this problem will surely not happen (not on XP, not on WIn7
and also not on Vista or WIn8), when you compile a small Test-Executable,
and try to call your Dll2.dll directly from this compiled Binary - it will work in
all cases.

An early info about that, would also have given a good hint to us, what's going
wrong.

And what's going wrong is, that you will have those problems only in the VB6-IDE,
since the location where you placed that Dll2.dll is important.

If it sits "directly beside your compiled Executable", then everything will *always* work
fine (when you run the compiled executable).

If it's sitting directly beside a *.vbp - and you try to run that project in the IDE,
then it will work only fine, when the Folder which contains your Dll2.dll, is the
CurrentDirectory - and that is not always the case.

The Windows-Dll-Loader (the LoadLibrary-call) tries to find Dlls with a certain
pattern, in a certain lookup-order:
http://msdn.microsoft.com/en-us/libr...p_applications

The Host-Process when you work with a Project in the IDE is not your compiled
Binary - it's VB6.exe, which runs from a different path, usually not the path your *.vbp
is placed in.

And as already said, one can resolve those IDE-Problems with Dll-Lookups, when you load
them yourself with explicite full-paths as e.g. in your case:

LoadLibrary App.Path & "\Dll2.dll"

That's all.

Once the Dll is loaded into the VB6.exe process, it will get found there, when you
reach the line, where your declared Dll-call is first used in your Code - you successfully
performed a kind of "early Dll-loading on App-Startup" in this case.

Olaf