0
0

Guys, had anyone tried to use FSOUND_STREAM_Create() in Visual Basic 6 to get custom streams? My problem is that I’m not sure in the VB-like method signature of the callback function to pass to FSOUND_STREAM_Create().

I was trying to work with the following signature:

[code:2j2xr4pw]Public Function diStreamCallback(ByVal stream As Long, ByVal buffer As Long, ByVal length As Long, ByVal param As Long) As Byte[/code:2j2xr4pw]

There’s some additional complexity in my software, since I obtain the content of the buffer passed-in by FMOD from another DLL, but I think this does not really affect the problem mentioned above.

  • You must to post comments
0
0

I have tried it once, but I haven’t been able to get it working yet. I think you have to use AddressOf and such…

My solution was to create the actual stream callback in a C dll, that can be called from visual basic.

  • You must to post comments
0
0

We have just figured out with my friend that there is no solution to this problem currently.

The reason of why you can not have the callback working in/from VB is that the callback function’s signature is defined with __cdecl convention in FMOD, with which VB and AddressOf of Visual Basic can not collaborate (is not compatible).

If the function was defined with __stdcall convention, then it works. I’m not sure, but I guess that the __stdcall convention is the calling convention for WinAPI functions, and VB certainly misses some information due to the different calling mechanism.

I’d be curious what is the opinion of Bratt and KarLKox

  • You must to post comments
0
0

Well, I don’t know a lot more about the calling conventions than I’ve written in my prior post, but what if you try to make an FSOUND_STREAM_CreateEx or FSOUND_STREAM_CreateVB method which does the same as the original, but its callback does not expect cdecl? Would it mix the shit to distinguish whether to call back a cdecl function or the newly added stdcall function? Or is it at all possible to somehow “convert” one calling convention to another?

As far as I can see, with such a great tool like FMOD, it is very easy to work in VB and since learning VB is not so hard as learning e.g. C++ and MFC, a lot of people in the future might choose VB and or C# as the programming language to work with.

On he other hand, I’m not sure that adding and extra function to a non-COM dll wouldn’t break backward compatibility due to the changes in the function/export table.

  • You must to post comments
Showing 3 results
Your Answer

Please first to submit.