I have written an audio based application for controlling large numbers of audio files in a live situation (e.g. theatrical production) with mixing controls and sequencing etc. but I've hit a BIG problem when trying to distribute it....
It's written using DirectX 8.1 (4.08.01.0881) in VB using the VB SDK from Microsoft. I don't want to include directx setup in my installation as it'll be a huge download - and unnecessary if someone already has a current version installed. Problem is, when the software is put on a machine that has a different version - even a higher one - DirectX won't initialise Events. I get a (very useful) Automation Error||Unspecified Error message.
Here's the code....
Set gDX = New DirectX8
Set gDMP = gDX.DirectMusicPerformanceCreate
Set gDML = gDX.DirectMusicLoaderCreate
gDMP.InitAudio hwnd, DMUS_AUDIOF_BUFFERS Or DMUS_AUDIOF_STREAMING, dmusAudio
mEvent = gDX.CreateEvent(Me)
... gDX, gDMP, and gDML are all declared as global variables (DirectX8, DirectMusicPerformance8, DirectMusicLoader8), mEvent is a module level Long. This code is in a class module which Implements DirectXEvent8 and has a DirectXEvent8_DXCallback method. The error occurs on the gDX.CreateEvent(Me) line - but only in the compiled EXE on a machine with a higher version of directX on (tested with version 4.08.01.0901).
The class that this is in Implements DirectX8Event (which is the object type passed into CreateEvent) so Me - in this context - is a DirectXEvent.
This is not a problem with the code (I don't believe) as it works fine on my development machine and any machine with EXACTLY the same DirectX version.
Has anyone else had odd problems with their compiled DirectX apps when DirectX is upgraded??
OK - it just gets weirder...
If I compile the application as an ActiveX EXE, rather than a standard EXE, everything works fine....
Could it be because I'm using a Class as the DirectX8Event as opposed to the (probably more common) method of using a Form. There should be no reason why this would make a difference but hey, since when did that count for anything...
Why and How.. Private classes cannot be passed to outside components.
To whom it may concern, in case you have this issue, note that: [sorry for the bump but I thought this may be useful].
A Standard Exe does not directly support automation and can only have Private classes which cannot be passed to components outside the immediate project [like Dx8], in which case only a form can be used as it acts like a code module and like a public class. This is why the documentation states it must be a form because they have made the assumption [in the docs] that it is within a standard exe.
However an ActiveX Exe or ActiveX Dll can have public classes [the default is 'Multiuse' which is public but not suggested for this use] which can be passed to components outside the immediate project and will work as an implementation for DirectXEvent8 that can be passed to Dx8 [I always do this in a Dll for fast calls], but I would suggest setting the instancing of the class to 'PublicNotCreatable' so that outside clients cannot arbitrarily create the class whenever they want.
By the way, if you take the error number you received and call DxVBLibA.D3DX8.GetErrorString(Err.Number) it should give the name of the error constant which you can then look up and have a better idea of what is wrong. If it returns "Unknown" or an empty string then you can try the Error$(Err.Number) as it may be a Vb error, but if that gives '*-defined error' then mask it with the value 'Err.Number And &HFFFF&', then take that number and look it up in the MSDN under 'Trappable errors'.
I hope someone finds this useful.
"Oh Listy"..."Rimsy",.. ..."Ahghghaa!" Linux Mint is way cool! [and super easy to install as a dual boot]