Add support for the BEL control in Windows Terminal

[j4james]

Summary of the Pull Request

This PR makes the Windows Terminal play an audible sound when the BEL control character is output.

References

• There is a separate issue (Make terminal beeps highlight Windows Terminal in the taskbar, to get user attention when backgrounded #1608) to deal with configuring the BEL to trigger visual forms of notification.
• There was also an issue (Feature Request: disable bell #2360) requesting an option to disable the BEL, which should probably be reopened, because this PR does not include any such configuration.

PR Checklist

• Closes Terminal doesn’t support audible bell (BEL, 0x7) #4046
• CLA signed.
• Tests added/passed
• Documentation updated.
• Schema updated.
• I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan.

Detailed Description of the Pull Request / Additional comments

The BEL control was already being forwarded through conpty, so it was just a matter of hooking up the WarningBell dispatch method to actually play a sound. I've used the PlaySound API to output the sound configured for the "Critical Stop" system event (aka SystemHand), since that is the sound used in conhost.

Validation Steps Performed

I've manually confirmed that the terminal produces the expected sound when executing echo ^G in a cmd shell, or printf "\a" in a WSL bash shell.

[skyline75489]

Somewhat related to MSFT:14062483.

[DHowett]

Ah. ‘483 is a “complaint” that we changed the bell from a “ding” to the STOP sound in Windows 8(?) or so. I should cut that deliverable: we aren’t going to change it in conhost.

[j4james]

I'm not sure what's up with the CI bot. It appears to be failing in a feature test on this line:

terminal/src/host/ft_host/API_OutputTests.cpp

Line 101 in a13ccfd

VERIFY_WIN32_BOOL_SUCCEEDED(GetConsoleScreenBufferInfoEx(consoleOutputHandle, &sbiex));

I can't imagine that has anything to do with the changes in this PR.

[zadjii-msft]

🔔

[DHowett]

(leaving a block to formulate my thoughts)

[zadjii-msft]

You know what, I think I've come up with what I think Dustin's block is over - we probably want the bell to be played by the TermControl layer, not the Terminal layer. That way each control implementation can control how the sound is played. Sure, right now the TermControl and the WPF Control will probably want to do the same thing, but someone could theoretically imagine another control that wanted to be able to customize this further.

Piping this up one more level shouldn't be too hard...

[zadjii-msft]

Okay, yea this is better. Should we go ahead and implement this for the WPF control at the same time as well? (I won't block over that, we can always file a follow-up for that as well)

[j4james]

I'm a bit out of my depth here. Am I right in thinking I actually need to turn this into an event handler of some sort? So TermControl would then just fire the event, and something like TerminalPage would have registered a handler that does the actual sound playing? Then the WPF control could assumedly hook into the event in a similar way.

I've going to do a bit more digging and see how some of the other event handling code works, but I just want to make sure this is what you actually had in mind. Of if you think it's better for me to leave this for someone that knows what they're doing and I can do that to.

[zadjii-msft]

@j4james oh no, I don't think it needs to be that complicated. The WPFControl lives at the same layer as the TermControl (it's just embedded in VS instead of in the Terminal app). So in the same way that TermControl registers the function pointer for the callback with Terminal, so too would the WPF Control

[DHowett]

Mike anticipated my block perfectly! I think that we should pipe this up out of TermControl as an event that TerminalPage/TerminalApp can receive. It's annoying plumbing work, but it'll enable us to light up features like "tab highlight on BEL" (or "put 🔔 icon in tab on BEL") and flip the configuration for whether bells sound to being TerminalApp-only instead of having to push it down into TerminalControl via ITerminalSettings.

You can mimic the TabColorChanged or Initialized events -- they use TYPED_EVENT, the former with IInspectable arguments which pretty much indicates "these aren't used ignore them" -- and slap them down in the .idl and .h

TYPED_EVENT(X) emits three members: an event subscriber (token X(lambda)), an event unsubscriber (void X(token)) and a functor that dispatches to all listeners, _XHandler.

[j4james]

OK I've added the event handling now, and hooked up the TerminalPage class to that event to play the sound. I'm still no closer to making this work in the WPF control though. The only way I can see the cs code talking to TerminalCore was via native methods exported from HwndTerminal, which seems way more complicated than I expected. If you don't mind, maybe the WPF integration is best left for a follow-up PR, because I'm not going to be able to do much more on this for a day or two.

[DHowett]

Thanks for doing the event work for Cascadia. We can definitely hold WPF back for another change. It usually gets that treatment anyway 😄

[DHowett]

Excellent as always. Thanks!

[jarlva]

Is there a fix for the silent bell?
The bell is still silent in ubuntu 20 ( printf "\a" ) and windows cmd (echo ^G).

Terminal version 1.3.2651.0
Windows 2004
WSL2 Linux 4.19.128.

[skyline75489]

@jarlva I think you can expect this to be fixed in Windows Terminal 1.5, which will be released to public near the end of October.

[ghost]

🎉Windows Terminal Preview v1.5.3142.0 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes
• Store Download