Modal dialog originating from Adobe Flash Plugin

Having problems with building or using CEF's C/C++ APIs? This forum is here to help. Please do not post bug reports or feature requests here.

Re: Modal dialog originating from Adobe Flash Plugin

Postby ryanmolden » Fri Dec 28, 2012 1:11 am

the annoying alarm bell that is supposed to accompany the Adobe Flash Player dialog (the one that alerts the user about an unresponsive script in a movie) goes off


I suspect it is a bug in windows, I believe they play the sound by default inside things like ::MessageBox based on what icon the dialog is set to show with. It probably properly handles the NULL return from CreateWindow but doesn't skip the tone in such situations, which could be forgiven since I doubt 'install a CBT_HOOOK that suppresses modal dialogs and ensure the beep does not occur' was in their test matrix :)

A sledgehammer approach would be to simply mute the speaker and post a callback to unmute them, they should stay muted only a very short period of time, but it is definitely hacky and of course may be perceivable if there is other audio playing. I believe, using something like MF (Media Foundation) you can get a volume control that could be used to silence only the system sounds, and leave other audio unaffected, which is what you would want. You would want something like IMFAudioStreamVolume, but that (MF) is only available on Vista+, so that may not be an option depending on your support matrix.

When using the hook-method, apart from crashing the Plugin Process (that's the only process having the hook-mechanism active), is there anything else that a royal screw-up could inflict upon the process/system ?


If you provide a specific thread ID to SetWindowsHookEx (i.e. don't pass 0 for that param) then it only installs the hook for that specific thread, so you shouldn't be able to screw up anything but your own app with any bugs.

That said windows hooks aren't terribly scary (as long as you read the documentation and understand what is happening :)), you need to just ensure you call CallNextHookProc for messages you haven't handled. It (MSDN) says you should do it for every message, and always return what it returns, but that doesn't make sense as it wouldn't allow you to do things like respond to HCBT_CREATEWND with a non-zero return code in order to suppress the creation, which MSDN clearly says is supported. I believe as long as you call it for every other message, or even call it for every message (including HCBT_CREATEWND) and simply pass your own value back to your caller for HCBT_CREATEWND specifically that you should be fine.

Also you should call UnhookWindowsHookEx at some point (shutdown).

Ryan
ryanmolden
Techie
 
Posts: 12
Joined: Mon Dec 17, 2012 2:56 pm

Previous

Return to Support Forum

Who is online

Users browsing this forum: Google [Bot] and 214 guests