I’m trying to learn from adion’s code I found posted here, and one of the API calls is:
Public Declare Function FSOUND_Stream_PlayEx Lib “fmod.dll” Alias “_FSOUND_Stream_PlayEx@16” (ByVal Channel As Long, ByVal Stream As Long, ByVal DSP As Long, ByVal startpaused As Byte) As Long
but I get the error:
Can’t find DLL entry point _FSOUND_Stream_PlayEx@16 in fmod.dll
Here’s what I’m trying:
lpSong = FSOUND_Stream_OpenFile(FileString, FSOUND_NORMAL Or FSOUND_MPEGACCURATE, 0)
Call FSOUND_Stream_PlayEx(FSOUND_FREE, lpSong, vbEmpty, False)
I have the latest version of the DLL, is there something I’m forgetting? How can I “browse” the DLL to see the entry points? Thanks for any help!
- rando asked 16 years ago
That was it… Thanks for the timely suggestion. I was under the impression that VB looked for the DLL in the project dir first, then system, etc. Apparently I was wrong. I updated the win/sys dll and it works fine now.
I don’t have Dependency Walker installed. I’ll have to take a look at the CD to see if it’s on there, it sounds like exactly what I need.
Long live Fmod.
I uploaded the Dependency Walker for you. Here it is:
http://invis.free.anonymizer.com/http:/ … epends.zip
(size = about 150 KB)
Just run depends.exe and open the DLL file you want to view. You can also associate DLL files with the dependency walker if you want (VS does this automatically when it installs it)
[quote="rando":n8mt1jlc]That was it… Thanks for the timely suggestion. I was under the impression that VB looked for the DLL in the project dir first, then system, etc. Apparently I was wrong. I updated the win/sys dll and it works fine now. [/quote:n8mt1jlc]
It is correct in windows, that a dll is first looked for in the project dir, and then system, …
This would give no problems when running the compiled version of your program.
If you are however trying to debug the application from within visual basic, the real exe that is executing your code is vb.exe, which is located in your program files directory somewhere.
So windows will first look in your visual basic directory, in which you probably don’t have fmod.dll, and then in the system dir, where it found the older version.
Altough for debugging your application using the system directory is ok, it is not recommended when distributing your application.
So when you have an installer, make sure it drops fmod.dll in the application directory in order to prevent possible version conflicts.
- Adion answered 16 years ago
That’s because you probably don’t have fmod.dll in C:\Windows\System.
1. Look in executable’s directory
2. Look in system directory
3. Look in current directory.
Yours works fine because VB sets the current directory to the project folder when an app starts. Since fmod.dll is in neither Program Files\Microsoft Visual Studio\VB98 or Windows\System, Windows uses the one in the current directory. In the case of rando’s situation, he had an older version in Windows\System, so the current directory wasn’t even looked at there.
Browsing DLLs? I’m pretty sure most VS products (not sure about VB) come with the Dependency Walker, which lets you view functions exported from DLLs. Since I’m not sure you have it or not, I’ll do it for you…
Hmmm, “_FSOUND_Stream_PlayEx@16” is correct; are you POSITIVE the DLL being loaded by VB is the latest? Also, if you have an older fmod.dll somewhere Windows might see it before the one in your VB app’s folder (for example, in c:\windows\system), Windows might get that one first. Search your system for fmod.dll, and update all of them with the newest DLL. Then try running your app again.
Please login first to submit.