I am a current user of the DLL edition 3.0.2 release and have just taken a look at the 3.1 demo. I was relieved to see that the SetEventListener export is still part of the API. Since the function is (at least) since the 3.0.2 release marked as DEPRECATED my question, if there is an answer to it just now, is wheter or not you plan to drop FPCSetEventListener from the API.
If so, I would ask you to reconsider this, because it's the only way to process messages without hacking into the host application's message loop.
For one thing this can be tedious (I'm a VCL user and thus far, not a single flash notification has made it to my - global! - listener, regardless of the ocx version). Also, requiring a section of flash integration code to reside inside the parent window's message loop makes it nearly impossible to isolate the flash hosting code from the rest of the application. This is especially true, if the application in question uses flash not as an interface element (like any other visible control) but rather as an imaging or logic resource.
I've seen you recommend the use of FPCSetEventListener throughout this forum especially when trouble with the FSCommand notification arises and I would think that the host of people that start working from your DirectX texture sample would have a much easier time simply creating an invisible flash control window and placing an event listener on it instead of being required to implement a complete hosting window class.
I realize this post ran rather long and I'm sure you have your own reasons to deprecate and phase out the event listener but I thought I'd try to make the case for keeping it.
thank you for your time.