I’m positive I’m missing out on something, as everybody else’s problems are all very complex, and mine is very simple. I’ve implemented callbacks via the AddressOf function in VB, and I’m going to use it to call my form when the stream has finished playing. Now that’s all fine but what do I use for the “user code”? I’ve had horrible luck with VB crashing EVERYTHING that’s on in Windows, and I don’t want to experiment because of that (usually requires a reboot, and that takes maybe 20 minutes on my P-II 200 :(). So, would I use it like this?
FSOUND_Stream_SetEndCallback lbgmusic, AddressOf MyWndProc, WhatData
Function MyWndProc(ByVal hw As Long, ByVal uMsg As Long, ByVal wParam As
Long, ByVal lParam As Long) As Long
If uMsg = WhatData Then
... whatever I want to do ...
MyWndProc = CallWindowProc(OldProc, hw, uMsg, wParam, lParam)
Thanks for whatever input you can give; Once I get more experienced with this I’ll try to give back to the forum as much as I chew off
Wow, thanks a lot for the replies! I recall you saying that adding support for VB would break backward compatibility…. But if not that’s great. The problem is that VB needs stdcall for the callbacks (like Adion has said). Therefore, different callback functions need to be created, so that VB can use its AddressOf function to give the location of the SoundCallback procedure. What I was hoping someone with knowledge of C++ would do is make something that simply changes the song on the end of the other; unfortunately this does not give enough flexibility. I have thought of two ways:
Make stdcall functions that work with VB for all of the callback things, so that it can be done in VB (ex. FSOUND_Stream_SetEndCallBack … AddressOf SoundCallback …).
Make a wrapper function like the one above, but instead passing the location of a function you’d like the callback to call. So it would be the above pseudocode, but it would execute your function that you pass to it with VB instead of just changing the song.
Thanks for the prompt support
Does redeclaring function callback will break compatiblity ? The solution for adding support for VB users can be done with redeclaring those functions like this :
typedef signed char (_cdecl *FSOUND_STREAMCALLBACK) (FSOUND_STREAM *stream, void *buff, int len, int param);
DLL_API FSOUND_STREAM * F_API FSOUND_Stream_Create(FSOUND_STREAMCALLBACK callback, int length, unsigned int mode, int samplerate, int userdata);
we would have
typedef signed char (CALLBACK FSOUND_STREAMCALLBACK) (FSOUND_STREAM *stream, void *buff, int len, int param);
DLL_API FSOUND_STREAM * F_API FSOUND_Stream_Create(FSOUND_STREAMCALLBACK *callback, int length, unsigned int mode, int samplerate, int userdata);
CALLBACK is defined in <windows.h>
Note that BlackShard coded a DLL wich add support for VB DSP callback.
VB uses stdcall calling conventions, while I’m sure FMOD uses cdecl (as usual for C/C++ projects). I don’t think FMOD might use fastcall conventions
However converting from cdecl to stdcall may broke compatibility with other software.
I already made a wrapper for VB with support for some FMOD callbacks, like FSOUND_DSP_Create, FMUSIC_SetRowCallback, FSOUND_Stream_SetEndCallback, …
I may send source code and binaries to everyone who is interested!
Alright, after finally figuring out the search “feature”, I found a few relevant topics, which unfortunately explained that use of a C++ wrapper function (do-it-yourself :(). Is somebody interested in writing a 2 minute DLL? To tell the truth I suck horribly at C++… I was never able to grasp it.
Here’s some help to anyone who would do this, what I’d like is to be able to play a different stream on the end of the other:
int VBStreamEndCall(FSOUND_STREAM current, FSOUND_STREAM newstream)
FSOUND_Stream_SetEndCallback(current, VBCallBack, (int)0);
signed char VBCallBack(FSOUND_STREAM *stream, void *buf, int len, int param)
And that’s all. I hope someone can help And once again I’m sorry for my lousy programming skills…
Please login first to submit.