We are currently migrating Bugzilla to GitHub issues.
Any changes made to the bug tracker now will be lost, so please do not post new bugs or make changes to them.
When we're done, all bug URLs will redirect to their equivalent location on the new bug tracker.

this didn't happen with SDL1

SDL1:
https://github.com/spurious/SDL-mirror/blob/release-1.2.15/src/video/windib/SDL_dibevents.c#L271

"return 0"

vs

https://github.com/spurious/SDL-mirror/blob/f8662b28634522fe409d5e7c8a7d0d5fc894e7cf/src/video/windows/SDL_windowsevents.c#L570

returnCode = 0;
-> return CallWindowProc


(not sure if correct, but it very likely looks like a bug as behaviour changed)

this is the same report as #865 it seems which was fixed but broken again...

this fixed #865

https://hg.libsdl.org/SDL/rev/4384

I'm not certain this is a bug, though it is surely annoying. But for example, the same beep occurs in Visual Studio and some other window programs, when an invalid menu accelerator combo is used. Windows is quite noisy, which is why I mute all these sounds, but anyway...

I used Spy++ to see what kind of events were getting passed around my SDL2 window. The one that causes this beep as far as I can tell is WM_MENUCHAR, and according to MSDN if its handler returns a 0 (MNC_IGNORE) it will beep: http://msdn.microsoft.com/en-us/library/windows/desktop/ms646349%28v=vs.85%29.aspx

I tried a quick hack in SDL to handle this message by returning MNC_CLOSE, but it had no effect, maybe I can't override this in the app? To confirm my suspicion, I removed the WS_SYSMENU style flag from SDL2's normal window style, and - no beep! but no system menu either.

Someone with more Windows API experience should look and see if something else is going wrong or if there's a good way to handle this.

Created attachment 1874 [details]
Handle the WM_MENUCHAR message to stop the beeping when Alt modifier key is used

Found more information about this from MS: http://support.microsoft.com/kb/92527

And that led me to a solution, I wasn't constructing the LRESULT properly in my last test. The attached patch stops the beep in an SDL window when Alt+[key] is used. One thing I still notice is the mouse cursor briefly flickers to the default cursor from my application's custom one, which occurred before the patch and may be related.

patch works for me, i'll get (hopefully) some more feedback from

http://springrts.com/mantis/view.php?id=4442

soon.

> I still notice is the mouse cursor briefly flickers to the default cursor from my application's custom one, which occurred before the patch and may be related.

this happens for me, too but it happened already before the patch, so no big deal. but thats imo a slightly different bug.

the beep seems fixed by this patch, others verified that, too. thanks for helping!

The correct fix for this is to handle the WM_SYSCOMMAND SC_KEYMENU and return similar to how SDL2 currently eats SC_SCREENSAVE / SC_MONITORPOWER

Located https://hg.libsdl.org/SDL/file/8d826bc39a45/src/video/windows/SDL_windowsevents.c#l795

compare wParam & 0xFFF0 and if it is equal to SC_KEYMENU, return 0 (or optionally add a flag like the screensaver though default to true maybe?

This bug is same as #865, reporting there as well.

Created attachment 2037 [details]
Handle the SC_KEYMENU message to stop the beeping when Alt modifier key is used

Alternative solution proposed by ensiform@gmail.com, prevents the beep but also stops the cursor flicker seen in the previous patch.

Does it need the ifdef SC_KEYMENU like the other two or is it supported much older than the other two SC_ defines?

(In reply to ensiform from comment #12)
> Does it need the ifdef SC_KEYMENU like the other two or is it supported much
> older than the other two SC_ defines?

I wondered, but the only documentation I've found from MS is that WM_SYSCOMMAND is supported on Windows 2000 or later. According to https://wiki.libsdl.org/Installation#Windows_95.2F98.2FME and https://wiki.libsdl.org/FAQWindows even Windows 2000 is no longer a supported platform for SDL 2.0.

(sorry if you get a lot of copies of this email, I'm marking several bugs at once)

Marking bugs for the (mostly) final 2.0.4 TODO list. This means we're hoping to resolve this bug before 2.0.4 ships if possible. In a perfect world, the open bug count with the target-2.0.4 keyword is zero when we ship.

(Note that closing a bug report as WONTFIX, INVALID or WORKSFORME might still happen.)

--ryan.

This patch is now https://hg.libsdl.org/SDL/rev/c5e1c4b7b7a1, thanks!

--ryan.