Declaring DLL - works only sometimes 1

[Motor11]

I have a project which accesses a .dll. I have sucessfully accessed the dll in the past by packaging it under the subdirectory with my project. I have declared and used this dll without any problems.

Now I am working on a new project on a new Windows 2000 machine. The exact same code to declare this dll and call the functions within it. The program will run correctly after I start VB -but only the first time. If I try to run the program (from the design environment) a second time, I get the error message "File Not Found: myfile.dll". The program will again run correctly when when I re-start VB, but it is a real pain to have to restart the design environment every time I test my app.

I have tried registering the dll with regsvr32, but I get the dreaded "Loadlibrary failed - the specified module can not be found" error. I believe only certain kinds of DLL's can be registered this way, but I know I've called functions from this dll in the past -using these same function call. What's going on here?

Best regards,
Ryan

 

[ArtieChoke]

Do you specify the entire path name of the dll file in the declare? It sounds like VB (or your program) is changing the working directory and it can't find the file after that (or maybe even just after a file save).

You can also put the dll's directory in the path variable in the environment. Then VB should be able to find it.

You are correct - only ActiveX/COM dll files get registered.

"I think we're all Bozos on this bus!" - Firesign Theatre

 

[NetGiant]

Wild shot in the dark ... does your app change the active directory? Try this: temporarily move the DLL to one of the system directories (WinNT or WinNT\System32) and see if your app will run more than just the first time.

Windows 2000 and XP (and NT?) use a different search method when trying to locate DLL files than Windows 9x. What OS were you using when you were able to work with the DLL successfully?

Only COM components are registered with regsvr32. If you *must* use "Declare" statements in your code then the DLL is almost certainly *not* a COM DLL.

I believe you would get that error message if the DLL you want to use can't find some of the DLL's it depends on.



Net_Giant

What fun is a technology if you can't crash the OS?

 

[Motor11]

Thanks for the comments,

Yes, my app does change the active directory. Actually, I pasted the code that runs on form-load to change this directory and call a function in the dll directly from my other app that works correctly. I have also tried to copy my dll to the system32 directlry with no luck. NetGiant may, however, be on to something with his suggestion that my dll may not find some of the dll's that it depends on. I do have another dll that I don't access through VB code but is needed. I haven't tried copying that to the system32 directory, but that is the next step -good suggestion.

I will post my results (for the sake of completing the thread).

Thanks again,
Ryan

 

[NetGiant]

It sounds like this is the sequence of events.

1) app is started in IDE
2) DLL function invoked successfully
3) current directory on the drive with the app is changed
4) app is closed

5) app is started again in IDE
6) DLL cannot be found because it is not in the current directory (changed in step 3 above)
7) app errors out because DLL call failed

Does that seem plausible? That's my theory anway.

If your DLL has many supporting components, other DLLs require by the DLL you call, then it may be easier to add their directory to the path. That may not be a viable solution when you complete and distribute your app but it may be easier than copying 10 or more files to your system folder and then have to take tham all back out again.


Net_Giant

What fun is a technology if you can't crash the OS?

 

[Motor11]

The first thing I do when I start the app is to change directory -before I invoke any function in the DLL. I'm not sure it's the chdir, but I may try to find a way to get rid of it (at least for testing purposes).

For now, your earlier suggestion has done the trick (hence the star). I had copied my dll into system32, but not the supporting dll. Copying the other dll has made the program behave in the design environment.

So things are good for now. Of course, I may have other issues when I attempt to distribute the darn thing.

Best regards,
Ryan