Wann/Warum spielt Windows die Standard-Sounds?

[zeckensack]

Ich habe ein kleines Support-Problem. Auf meinem Rechner sind jegliche Windows-Sounds deaktiviert, deswegen ist mir das selbst nie aufgefallen. Sei's drum.

Es erklingt in ein paar Spielen das "Standardsignal" von Windows, wenn die linke Maustaste gedrückt wird. Das ist natürlich etwas irritierend. Ich habe auf meiner MSDN-CD leider nichts hilfreiches zu den Windows-Sounds gefunden, und kann mir nicht erklären, warum das passiert.

'Mein' Fenster ist ein bildfüllendes, inaktives Fenster, also ohne Input-Fokus, aber trotzdem sichtbar:

HINSTANCE hInst;
WNDCLASS output_window_class;
ATOM output_window_class_atom;

HWND
open_window(int x,int y)
{
memset(&output_window_class,0,sizeof(output_window_class));

output_window_class.style=CS_OWNDC|CS_NOCLOSE;
output_window_class.lpfnWndProc=DefWindowProc;
output_window_class.lpszClassName="RGlide";
output_window_class.hInstance=hInst;

output_window_class_atom=RegisterClass(&output_window_class);

HWND window=CreateWindow("RGlide","RGlide",
WS_POPUP|WS_DISABLED|WS_CLIPCHILDREN|WS_CLIPSIBLINGS,
0,0,x,y,NULL,NULL,hInst,NULL);

if (window)
{
SetWindowPos(window,HWND_TOPMOST,0,0,0,0,SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE|SW P_NOSENDCHANGING);
ShowWindow(window,SW_SHOWNA);
}

return(window);
}

Wie man sieht, verarbeite ich keine Window-Messages (DefWndProc). Input-Messages gehen auch nicht an mein Fenster, sondern an ein Client-Fenster (das aktiv ist, aber von 'meinem' Fenster verdeckt wird). Ja, das funktioniert.

... nur eben diese akustischen Signale. Was könnte das sein?

[Xmas]

Mir scheint, DefWndProc ist vielleicht nicht ganz das was du brauchst. Versuch doch mal die Messages aufzuzeichnen, die dein Fenster erhält. Oder eine WndProc, die alle LBUTTON-Messages einfach ignoriert und den Rest an DefWndProc weitergibt.

[Matti]

Wenn du ein Fenster anclickst, das keine Input-Messages verarbeiten kann, kommt afaik immer ein Windows-Ton, falls der Soundeffekt aktiviert ist.

[zeckensack]

Matti,
rein technisch betrachtet verarbeitet das Fenster sehr wohl Window-Messages, und zwar mit dem Default-Handler, der in 99% aller Applikationen zumindest einen Teil der Messages bearbeitet, und dieser Aufgabe durchaus gewachsen ist.

Das Problem war folgendes:
WM_SETCURSOR
<...>
The DefWindowProc function passes the WM_SETCURSOR message to a parent window before processing. If the parent window returns TRUE, further processing is halted. Passing the message to a window's parent window gives the parent window control over the cursor's setting in a child window. The DefWindowProc function also uses this message to set the cursor to an arrow if it is not in the client area, or to the registered class cursor if it is in the client area. If the low-order word of the lParam parameter is HTERROR and the high-order word of lParam specifies that one of the mouse buttons is pressed, DefWindowProc calls the MessageBeep function.

*gnarf* (http://msdn.microsoft.com/library/en-us/winui/WinUI/WindowsUserInterface/Resources/Cursors/CursorReference/CursorMessages/WM_SETCURSOR.asp)

Mein Problem ist damit jedenfalls gelöst.
LRESULT CALLBACK
GlideWindowProc(HWND window,UINT message,WPARAM wp,LPARAM lp)
{
#ifdef LOG_WINDOW_MESSAGES
if (!msg_log_open)
{
msg_log=fopen("_Gmsg","w");
msg_log_open=true;
}
fprintf(msg_log,"Window 0x%08X receives message 0x%08X, w=0x%08X, l=0x%08X\n",window,message,wp,lp);
#endif

switch(message)
{
case(WM_SETCURSOR):
return(TRUE);
break;
}

return(DefWindowProc(window,message,wp,lp));
}