The standalone/projector player doesn't using the ActiveX plugin, it uses its own contained player runtime. I think you are correct it sounds like an error is getting thrown upon context3D creation. Make sure you add an Event.ERROR listener to the stage before requesting the context3d:
stage.stage3Ds.addEventListener( ErrorEvent.ERROR, handleError );
Also if you get that far it would you should turn on context3D.enableErrorChecking = true in case there are some other failures down the pipeline. Unfortunately embedded ActiveX plugin in custom apps is not officially supported, but I'd like to help you with any debugging if I can.
Hi Charbs, thanks for the reply.
I've done a bit more investigation, my application doesn't display any content if I set wmode to direct, even when I try and play a very simple .swf that in no way will be using stage3D.
I'm now assuming that setting direct wmode forces the .ocx to attempt rendering using Direct3D regardless of whether I use any Stage3D or not. It would be interesting to find out if it is possible to set wmode to direct, and disable any use of Direct3D, although I suspect that setting wmode to direct would at least use Direct3D as its viewport regardless of any type of display generated by the swf.
I will investigate the Event.ERROR suggestion, but I'm not a Flash/AS programmer at all, I wouldn't know wher to start so this might take a while - unless any of you helpful souls might knock something up to output/log any error messages from a simple stage3d swf?
Also, I suspect that how I currently capture the display output and then transfer that to my own Direct3d texture/surface might not be compatible with how direct mode works. Is there any in depth technical documentation for how the ocx or projector handle direct wmode?
I had a quick poke at this again recently, I now think the problem is because I was using a windowless ocx container, and the 'direct' wmode doesn't like that. I tried a simple windowed ATL example and it successfully handled the stage3D .swf. I also had a look at the NSAPI approach, which I hadn't come across before, which opens up possibilities in more ways than one.
When I get a chance I'll rewrite my non ATL code... I'll report back... maybe this year!