loadlibrary - location problem

I have a VB6 dll wrapper that wraps around an ocx that wraps around a non-com windows dll. Although the ocx and non-com dll sit in the same folder, the ocx cannot load the non-com unless it (the non-com dll) is placed in system32.

Why is this, and how can we force the ocx to look for the non-com in the same folder as the ocx?

A few details:
- Both the ocx and the non-com are vc++ and were not written by me, but by another programmer at my company
- I asked the programmer to put ".\" in his loadlibrary in the ocx, hoping it would see the non-com in the same location - didn't work
- when the non-com is in system32 it works, otherwise the ocx is unable to load the non-com and it fails
LVL 11
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Do this in your OCX (I'm assuming it's implemented using MFC, if not, you'll have to obviously change the code to eliminate the MFC dependencies):

CString sDLLFilename = _T("NonComDll.dll");     // replace this with the file name of your non-COM DLL

CString sPathname;      // full path and file name of the current module (OCX)
VERIFY(::GetModuleFileName(NULL, sPathname.GetBuffer(MAX_PATH), MAX_PATH));
int nDirEnd = sPathname.ReverseFind(_T('\\'));
sPathname = sPathname.Left(nDirEnd+1) + sDLLFilename;


Needless to say you'll have to add error checking to the code. Also, ReverseFind(_T('\\')) is not necessarily the best way to extract the directory component, but I thought it would suffice for an example.

VB6 API calls are implemented using LoadLibrary function which searches for executable in the following directories:
The directory from which the application loaded (exe file and not ocx server).
The current directory.
The system directory.
The Windows directory.
The directories that are listed in the PATH environment variable.

Directory where ocx is placed in not part of this list. You can try to add required directory using SetDllDirectory API. I am not sure this will help, but it is easy to check. Another way is to set current directory (SetCurrentDirectory API) before API call. Or ensure that Dll is in one of directories where LoadLibrary can find it.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
System Programming

From novice to tech pro — start learning today.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.