Windows Error 'BING' Sound - Accepting Single Inputs

Include Version 5 of Basic Screen Effects by Emily Short.

Keypress is an indexed text variable.

To get char input:
	let keychar be the chosen letter;
	now keypress is keychar resolved to an indexed text;
	
To decide which indexed text is (N - a number) resolved to an/-- indexed text:
	if (N > 31 and N < 127) or (N > 160 and N < 384):[i.e., we have received printable input]
		decide on "[char-code (N)]";
	otherwise:
		decide on "".
	
To say char-code (N - a number):
   (- print (char) {N}; -)

To advance the screen:
	say "[paragraph break]Press 'c' to continue.";
	now keypress is "";
	let still_waiting be true;
	while still_waiting is true:  [BING!]
		[get char input;]
		if keypress is "c" or keypress is "C", now still_waiting is false;
	clear the screen;
	say "[line break]";

I use this ‘advance the screen’ functionality across many projects, and I’m ashamed to say that for a long time I’ve been ignoring the constant ‘bing’ noise that it causes.

It seems that whenever you press a keystroke while i7 is ‘processing’, it causes a Windows notification error-type sound to play. The above code invokes this behavior because it relies on a ‘while’ loop, which is interrupted by key presses. Does anyone know of a workaround or fix for this issue?

The intention of the code is to react immediately to a keypress, without the ‘ENTER’ key being pressed. Aside from using this for clearing the screen (frequently), I also use this for timed player responses, where there are multiple letter choices presented. What I’m getting at, is that I am MARRIED to this functionality. I really need to find a way to make it work.

The ideal solution would be to read inputs directly, one-by-one, without an infinite loop behavior occurring on the i7 layer. Perhaps this is something that can be more easily accomplished with i6?

Include Version 5 of Basic Screen Effects by Emily Short.

Keychar is a number variable.
Keypress is an indexed text variable.

To get char input:
	now keychar is the chosen letter;
	now keypress is keychar resolved to an indexed text;
	
To decide which indexed text is (N - a number) resolved to an/-- indexed text:
	if (N > 31 and N < 127) or (N > 160 and N < 384):[i.e., we have received printable input]
		decide on "[char-code (N)]";
	otherwise:
		decide on "".
	
To say char-code (N - a number):
   (- print (char) {N}; -)

To advance the screen:
	say "[paragraph break]Press 'c' to continue.";
	wait for the C key;
	clear the screen;
	say "[line break]";

To wait for the/-- C key:
	(- CPause(); -).

Include (-

[ CPause i;
	while (i ~= 67 or 99)
	{
		i = VM_KeyChar();	
	}
];

-).

I’ve pulled some code from Version 5 of Basic Screen Effects by Emily Short.
This is fundamentally the same thing as before, but now the while loop exists solely in the i6 code. I’m still hearing the same ‘BING’ sound whenever I input a keypress.

EDIT: Let me know if this is more appropriate in the i6 section. I’m not sure what exactly is causing the issue.

EDIT: I’ve come to understand that this sound is known as the ‘asterisk’ sound, and is related to the Windows operating system.

The way you’re handling keystroke input isn’t wrong as far as I can see. It’s important to remember that the chosen letter phrase blocks and waits for the next keystroke. So there shouldn’t be any point when I7 is “processing”. It’s always waiting for your next keystroke.

(Of course, in your first sample, you have the line “get char input” commented out. That is an infinite loop; don’t do that…)

You can simplify your code somewhat without going to the I6 level. This works fine, at least for me:

To advance the screen:
	say "[paragraph break]Press 'c' to continue.";
	let still_waiting be true;
	while still_waiting is true:
		let keypress be the chosen letter;
		if keypress is 67 or keypress is 99, now still_waiting is false;
	clear the screen;
	say "[line break]";

I’ve dropped the conversion to indexed text; it’s not necessary. The chosen letter phrase returns a number which is an ASCII code, and you already know how to check that for upper and lower case C.

If you look into the Basic Screen Effects source, you’ll see a phrase wait for the SPACE key which is essentially identical to your I6 version. (Possibly you got yours from there!)

[ SPACEPause i;
	while (i ~= 13 or 31 or 32)
	{
		i = VM_KeyChar();	
	}
];

Thank you for the simplification. I definitely took my code from Basic Screen Effects, and also a few forum posts probably. I’m starting to think that this block isn’t causing the issue at all, but that the issue is being set up BEFORE certain moments where I call ‘advance the screen’. I’m turning my suspicion toward other frequently used functions.

I assume that this is in the Windows Inform 7 front-end, and not some other interpreter? You don’t say, but that’s what is implied.

Anyway, there was an issue in the Windows Inform 7 front-end that caused spurious error signals on character input. It is fixed, but only in the latest betas from the development page, Release Inform7 6M62 Win64 beta 3 · DavidKinder/Windows-Inform7 · GitHub

If you’ve got a 64-bit Windows 10 install (which is nearly everyone these days) then install that version and see if the problem is dealt with.

1 Like

This worked! You have no idea how happy this makes me! I’ve been suffering that noise for the better part of a decade, too lazy to chase down a solution. Thank you so much!

I should mention that I’m on Windows 8.1, but everything seems to work just fine. Hallelujah!

1 Like

Good to hear it works, and on Windows 8.1 too. It should work on Windows as far back as 7, but I’ve now no way to test that.