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.
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!