VolumeMute KeyPress - can't cancel event after processing

Question

I have C# app that monitors keystrokes via KeyDown and KeyPress events. Specifically, it watches for a VolumeMute keystroke (from a handheld device) to do some special processing. It works fine with one problem: Windows seems to intercept the VolumeMute keystroke and mutes the system volume (which I don't want to happen). I think Windows intercepts the keystroke before it is processed by my app because even when I signal the keystroke was handled (e.Handled = true), it mutes the system volume anyway. BTW, the same code works perfectly for other keystrokes I'm catching (ex Backspace, ect).

Is there a way to stop Windows from doing this volume mute?

System: WinXP SP3, .Net 4 Client Profile, Windows Forms app

Code snips

    bool keyHandled = false;

    private void Form1_KeyPress(object sender, KeyPressEventArgs e)
    {
        if (keyHandled)
        {
            e.Handled = true;
        }
    }
    // =====================================
    private void Form1_KeyDown(object sender, KeyEventArgs e)
    {
        keyHandled = false;



        switch (e.KeyCode)
        {

            case Keys.VolumeMute:
                DoSpecialProcessing(); 
                keyHandled = true;
                break;
            default:

                break;
        }

        e.Handled = keyHandled;

    }

What's the point? The user will switch to another app, mute, switch back. Or just use the tray icon. — Hans Passant, Jun 06 '12 at 23:29
Hans, we're trying to repurpose a remote controller that sends keystrokes when you push its buttons. One button sends a VolumeMute keystroke. We want to perform a different function (rather than muting sound) when this button is pressed. — LT Dan, Jun 06 '12 at 23:46

score 0 · Answer 1 · edited May 23 '17 at 11:55

0

The button acts like a toggle, it will mute on the first press and "un-mute" on the next press. All you need is to simulate VolumeMute press again.

This answer explains how to do it.

Note: If you call this method from inside KeyDown handler then you probably need to use BeginInvoke or PostMessage to post a message to a message queue and return immediately in order to avoid race conditions.

edited May 23 '17 at 11:55

Community

1
1

answered Jun 07 '12 at 00:57

Jacob Seleznev

8,013
3
24
34

Thanks Jacob. But I'm not trying to mute/umute the system sound. I want to *prevent* Windows from performing mute/umute with this keystroke. My app is able to trap the VolumeMute keystroke and do its processing. But I can't prevent Windows from also performing mute/umute toggle (which I want to suppress). – LT Dan Jun 07 '12 at 11:57
I understand. If you simulate another VolumeMute press after KeyDown event the end result will be as if you suppressed default Windows action. Am I right? – Jacob Seleznev Jun 07 '12 at 12:21
Ah, I see what you are saying now. Yes, that would probably work. Although not as clean a solution as I'd like. I'm testing AutoHotKey to see if I can remap VolumeMute keystroke to another key *before* Windows sees it. I'll post the result here incase anyone else wants to know. – LT Dan Jun 07 '12 at 13:54

score 0 · Answer 2 · answered Jun 07 '12 at 19:03

Ok. I ended up using AutoHotKey to remap the VolumeMute to another key. Importantly, Windows never sees the VolumeMute keystroke before it gets remapped and doesn't mute the sound. So I can just start this AutoHotKey remap script when I need it. Beats messing with the Windows Registry. Thanks for the suggestions.

VolumeMute KeyPress - can't cancel event after processing

2 Answers2